Saltar al contenido

Arquitectura

De la intención de negocio a producción.

La ingeniería de producto AI-native es un lifecycle disciplinado: los agentes ejecutan trabajo significativo en cada etapa mientras conservo criterio de producto, responsabilidad y autoridad de release.

HablemosRevisar trabajo
Sistema AOHYS en producciónUna señal entra. El sistema conserva el contexto y llega a producción con un release visible.
  1. 01
    Experiencia pública

    Sitio bilingüe, casos, servicios y accesibilidad

    Astro · EN / ES
  2. 02
    Contenido, dashboard y datos

    Publicación, ownership y contratos compartidos

    Content Graph · Convex
  3. 03
    Media y edge

    Imágenes publicadas, fallbacks versionados y entrega rápida

    Cloudflare
  4. 04
    Señales y contacto

    Solicitudes, analíticas y errores con límites explícitos

    Formulario · PostHog
  5. 05
    Tren de release

    Preview, checks, promoción y smoke de producción

    develop → main
Arquitectura

Un lifecycle, seis etapas con responsabilidad.

La secuencia hace visibles decisiones, dependencias, verificación y límites de release. AOHYS es una implementación pública de esta práctica, no el límite de la arquitectura ni un mapa del Development System privado.

  1. 01

    Intención de negocio

    Escuchar al negocio, aclarar el resultado de usuario, revelar restricciones y hacer grilling del lenguaje ambiguo antes de elegir un camino técnico.

    • Intención de negocio
    • Contexto de stakeholders
    • Grilling
    • Definición de resultados
  2. 02

    Dominio y decisiones

    Modelar el dominio, nombrar conceptos estables, comparar tradeoffs y registrar decisiones que dan forma al producto y al sistema.

    • Modelado de dominio
    • Decisiones de arquitectura
    • Límites de producto
    • Tradeoffs
  3. 03

    Specs y grafo de dependencias

    Convertir la dirección acordada en specs, tickets ejecutables, ownership, seams de aceptación y dependencias que conservan el orden correcto.

    • Specs y tickets
    • Grafo de dependencias
    • Criterios de aceptación
    • Límite de release
  4. 04

    Implementación con agentes

    Agentes especializados investigan, implementan, prueban y revisan trabajo acotado. El orquestador humano integra evidencia y resuelve decisiones que las herramientas no pueden asumir.

    • Implementación con agentes
    • Revisión especializada
    • Ingeniería de contexto
    • Orquestación humana
  5. 05

    Verificación y browser QA

    Usar TDD proporcional, linting, type checks, pruebas de comportamiento, revisión independiente y browser QA para verificar el resultado real y visible.

    • TDD
    • Code review
    • Browser QA
    • Evidencia visual
    • Observabilidad
  6. 06

    De preview a producción

    Construir un Preview Deployment, reunir revisión humana, promover mediante Release Train, verificar el Production Deployment y ejecutar smoke checks.

    • Preview Deployment
    • Release Train
    • Production Deployment
    • Smoke checks

La arquitectura es una secuencia de tradeoffs.

  1. 01

    Ejecución de agentes con responsabilidad humana

    Los agentes amplían la capacidad de ejecución, pero no pueden asumir intención de negocio, aceptación de riesgo ni autoridad de release.

    Sigo siendo responsable de lo que se construye, cómo se verifica y si está listo para release.
  2. 02

    Explicación pública sin publicar la herramienta privada

    El lifecycle debe ser inspeccionable sin exponer instrucciones privadas, métodos operativos ni detalles de entrega.

    El Development System permanece privado y adaptable; productos entregados y artefactos sanitizados aportan la evidencia.
  3. 03

    Preview antes que producción

    Un build verde no demuestra que un release funciona en su ambiente real.

    Promoción protegida, Preview Deployment, revisión humana y smoke checks vuelven producción una decisión separada.

Notas de operación

Los seams que mantienen conectada la topología.

  1. 01

    Responsabilidad humana

    Los agentes ejecutan requisitos, modelado, specs, tickets, implementación, pruebas, revisión y QA. Alejandro conserva criterio de producto, integra evidencia y autoriza el release.

  2. 02

    Public Source Site y Private Work

    El Public Source Site permite inspeccionar decisiones de implementación de AOHYS. Private Work —código de clientes, datos, pantallas operativas, credenciales y Development System— permanece privado.

  3. 03

    Release Train

    Primero se construye y revisa un Preview Deployment. Producción avanza mediante promoción separada con autoridad explícita, checks de ambiente, verificación de deployment y smoke checks en el dominio canónico.

  4. 04

    AOHYS como implementación visible

    AOHYS demuestra rutas públicas localizadas, workflows privados autenticados, contenido tipado, observabilidad y una ruta de release protegida. Es un ejemplo concreto de una arquitectura profesional más amplia.

  5. 05

    Development System privado

    El Development System coordina herramientas y agentes en distintos entornos de coding. Es privado, no open source ni template comercial, y cada equipo debe adaptar su propia práctica.

  6. 06

    Feedback de producción

    Observabilidad, analíticas, errores, smoke checks y feedback de stakeholders regresan el comportamiento real a la siguiente decisión de producto; release no es el final del lifecycle.

Cuéntame qué estás construyendo.

Cuéntame qué estás construyendo, a quién debe servir y qué lo está frenando. Leeré el contexto personalmente y responderé con preguntas útiles y un siguiente paso práctico.

Hablemos