ARIA — La Plataforma Interna que nos Hace Mejores

ARIA es la plataforma interna de iTechDev. Es un conjunto de herramientas, automatizaciones y dashboards que nuestros developers y arquitectos usan diariamente. La construimos nosotros, la mantenemos como cualquier producto serio (branch protection, code reviews obligatorios, tests, CI/CD) y la operamos en nuestra propia infraestructura privada.

Las áreas donde ARIA nos ayuda diariamente:

• Calidad de código: linting, tests, coverage gates, análisis de complejidad ciclomática.
• Seguridad: escaneo de vulnerabilidades, detección de secrets en commits, dependency audit, alertas de CVE.
• Productividad: skills validados que automatizan tareas repetitivas, asistencia inteligente con contexto del proyecto.
• Memoria organizacional: registro de decisiones técnicas, contexto de proyectos, conocimiento que sobrevive a rotación de equipo.
• Observabilidad: dashboards internos de salud de proyectos, métricas DORA, identificación de riesgos.

Esto es lo que sucede paso a paso desde el día 1 hasta producción:

Antes de que cualquier código llegue a producción, pasa por una cadena de validaciones automatizadas dentro de ARIA. No es opcional ni dependiente del developer:

• Linting automatizado por lenguaje (ESLint, golangci-lint, Pylint, RuboCop, SonarQube) que detecta anti-patterns y errores comunes antes del review humano.
• Test coverage gates obligatorios. Si una función crítica no tiene tests, el PR no se mergeaba. El threshold se configura por proyecto según riesgo.
• Complejidad ciclomática medida automáticamente. Funciones complejas se marcan para refactor o documentación adicional.
• Code review obligatorio con asistencia IA. Cada PR recibe una primera revisión de ARIA (estilo, errores, patterns) antes del review humano. El humano enfoca en lo conceptual.
• Branch protection en repos: no se mergea a main sin checks verdes + aprobación de CODEOWNERS.

El objetivo no es ralentizar — es garantizar que la barra de calidad sea la misma para todos los proyectos, independientemente de quién esté trabajando.

La seguridad la tratamos como infraestructura, no como auditoría posterior. ARIA escanea continuamente cada proyecto que tocamos:

• SAST (Static Application Security Testing) en cada PR. Detecta SQL injection, XSS, hardcoded credentials, weak crypto, path traversal, OWASP Top 10.
• Dependency audit automático. Cada commit revisa npm/pip/maven/gradle vs base de datos NVD. Alertas inmediatas cuando se descubre una CVE en un paquete que usamos.
• Secret scanning previo al commit (pre-commit hooks). Detecta API keys, tokens, passwords accidentalmente staged. Evitamos el ~70% de leaks comunes.
• Container scanning con Trivy en cada build de Docker. Si la imagen base tiene CVE crítica, el deployment se detiene.
• License compliance. ARIA verifica que las dependencias respetan las licencias permitidas según política del proyecto (MIT/Apache OK, GPL revisión, AGPL bloqueado).
• Alertas proactivas de CVE. Cuando se publica una vulnerabilidad nueva (Log4Shell, Spring4Shell tipo de evento), ARIA correlaciona automáticamente con todos nuestros proyectos activos y nos avisa cuáles están expuestos.

Para clientes en industrias reguladas (fintech con CNBV, salud con COFEPRIS), exportamos los logs completos del scanning para auditoría.

El ritmo de innovación en herramientas de desarrollo en 2026 es alto: nuevos scanners de seguridad, nuevos frameworks de testing, nuevas best practices, modelos de asistencia inteligente. Sin un sistema, los equipos se quedan rezagados porque cada developer adopta a su ritmo.

ARIA centraliza la evaluación e integración de herramientas nuevas:

• Skills system: cuando aparece un nuevo workflow útil (ej: auditar performance de un endpoint), lo convertimos en un "skill" validado disponible para todos los developers. PR-review obligatorio antes de aprobación.
• Asistencia inteligente: integramos modelos validados según nuestros estándares internos de seguridad y compliance. Los developers obtienen ayuda contextual al proyecto sin que tu organización deba gestionar suscripciones individuales ni exponer datos.
• Patrón "early adopter controlled": 1-2 proyectos prueban herramientas nuevas con monitoreo intensivo. Si funcionan, escalan a todos. Si no, se descartan documentadamente para no perder tiempo en re-evaluaciones.
• Knowledge sharing automatizado: cuando un developer resuelve un problema interesante, ARIA captura la solución y la disponibiliza al resto del equipo via memoria semántica.

No medimos velocidad como un objetivo aislado — la medimos para identificar dónde estamos perdiendo tiempo sin razón. ARIA recopila métricas DORA en todos los proyectos:

• Deployment frequency: cuántas veces deployamos a producción. Si baja, indica friction en el pipeline.
• Lead time for changes: desde commit hasta producción. Si sube, hay cuellos de botella.
• Change failure rate: porcentaje de deploys que requieren rollback o hotfix. Si sube, hay problemas de calidad o testing insuficiente.
• MTTR (mean time to recovery): tiempo de detección + corrección de incidentes. Si sube, hay déficit de observabilidad o runbooks.

Estos números los revisamos en retrospectivas mensuales. Si vemos degradación, investigamos causa raíz y aplicamos correctivo. No es métrica para presumir — es feedback loop interno.

Uno de los problemas más caros en cualquier proyecto de software es la pérdida de contexto: por qué se tomó una decisión, qué se probó antes, dónde está el código relevante, cómo se resolvió un bug específico hace 8 meses. Esa información típicamente vive en Slack, emails, cabezas de personas — y se pierde con rotación.

ARIA mantiene memoria persistente por proyecto:

• Decisiones técnicas con fecha, autor y razonamiento.
• Bugs resueltos y la solución completa (no solo el commit).
• Conversaciones relevantes con el cliente sobre alcance, requisitos, prioridades.
• Trade-offs explicados (por qué Postgres en lugar de MongoDB, por qué REST en lugar de GraphQL).
• Diagramas de arquitectura versionados.

Cuando un developer entra a un proyecto existente (o regresa después de semanas), ARIA le da contexto en minutos en lugar de días.

Cada cambio en ARIA o en los proyectos que opera está gobernado de la misma forma que el código serio en cualquier empresa enterprise:

• Branch protection en repos críticos. Main bloqueada — solo se mergea vía PR aprobado.
• CODEOWNERS definidos por área del código. Reviewers obligatorios según el archivo modificado.
• Audit logs de cada cambio: quién, cuándo, qué cambió, justificación.
• Skills system con PR review: agregar un skill nuevo (workflow automatizado) requiere PR aprobado por el skill maintainer. No se acepta código sin revisión.
• Hard enforcement en cloud + soft enforcement local: los developers pueden iterar local sin friction, pero al subir a cloud los gates son obligatorios.

Esto es lo que nos permite aceptar proyectos en industrias reguladas (CNBV fintech, INAI compliance) con confianza: el audit trail no es un add-on, es como operamos.