Process-as-code: la nueva disciplina que cambia por completo tu dev pipeline

Llamémoslo por su nombre: process-as-code.

Es el conjunto de archivos de texto que codifican cómo trabaja un equipo — convenciones, decisiones, patrones, anti-patrones, secuencias, criterios. Vivían dispersos en Confluence, en diapositivas, en la cabeza del senior con 8 años de tenure. Hoy viven en el repo:

• CLAUDE.md o AGENTS.md — instrucciones operativas para el agente
• decisions/ — ADRs vivos
• docs/ — markdown que documenta intent
• skills/ — playbooks por capability
• Templates de PR, prompts curados, scripts de orquestación

Process-as-code no es un nombre nuevo para “documentación”. Es un cambio de naturaleza: estos archivos se ejecutan. Cada vez que un agente arranca una tarea, los lee. Si están bien, el output es bueno. Si están mal, el output es slop. Si no existen, el agente improvisa — y ya hablamos aquí de qué pasa cuando un agente improvisa sin contexto.

El shift que de verdad cambió

Por décadas, la documentación de equipo era un artefacto muerto. La escribías para humanos. Si nadie la leía (caso común), no pasaba nada — el código funcionaba, el equipo seguía. La doc era opcional, casi decorativa.

En 2026, esos mismos archivos son un artefacto vivo: si tu agente los lee mal, tu PR sale mal. El loop de feedback se cerró. La doc dejó de ser opcional sin que nadie firmara un memo declarándolo.

Ese es el shift. No es una nueva práctica que adoptas. Es que la práctica vieja (escribir convenciones, documentar decisiones) se volvió load-bearing sin pedirte permiso.

Por qué esto no es BPMN otra vez

Cuando contamos esto, algún CTO con suficientes canas siempre dice lo mismo: “esto es lo que BPMN intentó hace 20 años. ¿Por qué va a funcionar esta vez?”.

Pregunta justa. BPMN —Business Process Model and Notation, estandarizada por OMG en 2004— prometía exactamente esto: procesos de negocio modelados como artefactos formales, máquina-legibles, ejecutables por un workflow engine. La industria invirtió billones en BPMN suites: Bizagi, Camunda, ActiveVOS, IBM BPM. La promesa era “el modelo es el código”.

Falló. ¿Por qué? Tres razones que importan ahora:

1. BPMN era top-down. Lo dibujaban analistas de negocio en herramientas separadas. Los developers veían diagramas que no correspondían a lo que ejecutaban. Process-as-code es bottom-up: el dev senior escribe el CLAUDE.md porque su agente lo necesita. Sin abogados de proceso. Sin comités.

2. BPMN era abstracto. El diagrama no era el código — generaba código, idealmente. En la práctica, generaba código horrible que nadie mantenía. Process-as-code es el código desde el primer carácter. Es markdown plano. Cero traducción.

3. BPMN estaba desconectado del repo. Los diagramas vivían en herramientas separadas con sus propios licenciamientos. El proceso y el código tenían su propio drift. Process-as-code vive junto al código, en el mismo PR, en el mismo git history. Si diverge del comportamiento real, lo notas en el siguiente commit.

BPMN fue el sueño correcto con la arquitectura equivocada. Process-as-code es el mismo sueño con la arquitectura que sí escala.

Lo que entra en process-as-code

Para aterrizar — no es vaporware, es lo que ya tienes (o deberías):

CLAUDE.md / AGENTS.md (raíz del repo)

Convenciones que el agente respeta: estilo, librerías preferidas, lo que NUNCA hacer. “Usamos tokens de design.css, nunca colores inline.” “Validación con Zod, no con if/else.” “Cuando dudes entre cachear vs query, default a query.”

decisions/ ADRs vivos

Una decisión arquitectónica = un archivo markdown. Contexto, opciones, elección, qué descartamos y por qué. El agente los lee antes de tocar arquitectura.

docs/playbooks/ skills

Cómo se hace X en este equipo. “Agregar un endpoint nuevo: pasos 1-7.” “Onboarding de cliente nuevo: checklist.” El agente puede ejecutar el playbook si tu prompt lo nombra.

Templates de PR / spec

Estructura obligatoria que el agente respeta cuando abre PRs o propone spec. “Cada PR debe incluir: intent, alternativas descartadas, tests añadidos.”

Prompts curados

Frases que sabes que producen output consistente para tareas recurrentes. “Refactorizar componente React: usa este prompt.”

Scripts de orquestación

Comandos custom que disparan al agente con context pre-cargado. “npm run agent:add-feature — abre Claude Code con el feature spec ya seteado.”

Todos esos archivos juntos son tu process-as-code. No es UN archivo. Es una capa.

Por qué se vuelve disciplina propia

Aquí está la predicción que no se nos quita: en 2-3 años, process-as-code engineering va a ser una disciplina con su propio rol, igual que SRE se diferenció de DevOps en los 2010s.

La señal: el rol que más está cambiando ya no es “el dev que mejor escribe código” — es “el dev que mejor cura el contexto para que el agente escriba código”. Eso ya está pasando en equipos que adoptaron AI coding agresivamente.

En 2027-2028 vamos a ver:

• Roles llamados “Context Engineer”, “Process-as-Code Lead”, “Agent Operations Engineer”
• Equipos enteros dedicados a mantener el process-as-code de la organización (igual que platform/devops teams hoy)
• Certificaciones y bootcamps especializados
• Conferencias dedicadas — AgentCon 2027, Context Engineering Day
• Herramientas de tooling para PAC (linters de CLAUDE.md, CI que detecta cuando ADRs divergen del código, etc.)

Es la siguiente capa de abstracción de la profesión. Y como pasó con DevOps, los equipos que la formalicen primero van a moverse 3-5x más rápido que los que sigan tratando estos archivos como “docs opcionales”.

Cosas que ya estamos viendo en proyectos

Lo que distingue equipos productivos de los que se quedaron atrás:

• CLAUDE.md de 200 líneas curado vs 20 líneas auto-generadas
• ADRs versionados con PR review vs decisiones en Slack que se pierden
• Templates de PR que el agente respeta vs PRs sin estructura
• Conocimiento tácito explicitado en playbooks vs “el senior sabe”
• Drift detection automatizado vs descubrir que el CLAUDE.md mintió cuando algo se rompe

Cada uno de esos puntos por separado se siente como overhead. En conjunto son lo que hace la diferencia entre output del equipo de 2026 y output del equipo de 2022 con AI bolt-on.

Y por cierto — eso que llamamos el nuevo moat? Vive exactamente aquí. Tu process-as-code es tu ventaja competitiva real ahora. Cuidarlo, evolucionarlo y proteger su evolución es lo que separa equipos que mantendrán margen de los que se diluirán en el promedio.

El estado del arte (incómodo)

La parte que importa decir en voz alta: la mayoría de equipos todavía no se da cuenta de esto. Siguen pensando en CLAUDE.md como “un archivo de configuración para Cursor”. Siguen escribiéndolo en 10 minutos y olvidándolo. Siguen pensando que su moat son las funciones de /utils.

Los que sí entienden ya están armando equipos alrededor de esto, contratando para el rol, midiéndolo, evolucionándolo semana-a-semana. La brecha es invisible desde afuera pero brutal desde adentro.

La pregunta que sí importa

Si tu equipo tuviera que reproducir su productividad actual mañana en otro stack, con otro lenguaje, otros frameworks — ¿qué tendrías que llevarte?

Si la respuesta es “el código de /utils”, estás en 2018. Si la respuesta es “el CLAUDE.md, los ADRs, los playbooks”, estás en 2026.

Process-as-code no es una práctica nueva. Es la práctica vieja volviéndose la práctica central — y los equipos que lo nombran, lo invierten y lo protegen son los que van a estar parados en 5 años.

---

Si tu equipo está empezando a sentir que el CLAUDE.md es más valioso que el /utils y quieren armar el resto de la disciplina, conversemos — el chat está abierto.