DEV M5 · Accelerators & IP Contribution — Resumen de estudio

Curso 5 de 5 · 25 pantallas, 9 checkpoints

"El punto donde el código empieza a funcionar es donde empieza el trabajo de este módulo." Que funcione no basta: tiene que poder reutilizarse, contribuirse, desplegarse con versión fijada y defenderse ante procurement y seguridad.

1. Empaquetar para reutilizar (accelerators)

Un accelerator es una solución empaquetada para que el siguiente proyecto la configure en vez de reconstruirla. Separa lo reutilizable de lo específico del cliente y expón lo específico como parámetros con valores por defecto documentados. Hazlo mientras el build está fresco.

• El error más común: entregar scripts sueltos en vez de un template. Funcionan, pero el siguiente equipo los copia y diverge.
• Documenta los supuestos, no solo el código: entorno, inputs esperados, fallos que ya maneja y el eval que define "funciona".
• Incluye el audit log en el paquete: qué datos toca, con qué identidad actúa y qué registro deja. Si no, pasa la demo y se atasca en la primera revisión de seguridad.

⚠️ Watch out: un template con la ruta del repo, el modelo, los umbrales y fragmentos de prompt hardcodeados, sin docs ni eval. El segundo equipo tuvo que reescribirlo. Que un template funcione no significa que esté empaquetado. Señales de alarma: sin parámetros, sin documentación de supuestos, sin eval.

Checkpoint 1: el valor hardcodeado es repo_path="/home/acme/checkout-service" → def build_review_agent(repo_path): … repo_path=repo_path.

2. Contribuir de vuelta al ecosistema

• Elige el canal según la forma de la contribución:
  • Claude Cookbook (GitHub): ejemplos de referencia enfocados que funcionan de punta a punta.
  • El repositorio propio de cada MCP server o tool, con sus convenciones.
  • Mandar una aplicación completa al Cookbook es un desajuste: se estanca.
• Un maintainer acepta lo que puede verificar:
  1. El código hace una sola cosa.
  2. Un ejemplo lo muestra funcionando.
  3. Un test prueba el comportamiento.
  4. Una breve declaración de supuestos.
• Derechos y atribución van ANTES de la revisión técnica: el código de un proyecto con cliente puede tener restricciones de licencia. Si no puedes resolverlas, no lo contribuyas: escálalo al dueño.

⚠️ Watch out: un PR de 3 semanas sin revisión. "Funciona, lo uso a diario", pero no tenía test, ni ejemplo, ni supuestos. Un PR se estanca en lo que el revisor no puede verificar.

Checkpoint 2:

• A (tool que envuelve una API) → el repositorio de la tool · le falta un test.
• B (aplicación completa) → el Cookbook, solo tras extraer el patrón reutilizable · le falta reducirla a un patrón enfocado.
• C (fix de una línea a un ejemplo, traído de un proyecto con cliente) → el repositorio de ese ejemplo · le falta la verificación de derechos (licencia).

3. Requisitos y ciclo de vida

• Requisito funcional: qué debe hacer el sistema, de forma verificable.
  • Ejemplo: "clasificar cada ticket en una de 4 colas; redactar una respuesta citando la política; nunca enviar sin aprobación humana".
• Requisitos de infraestructura (no funcionales; se derivan preguntando): latencia (medida donde está el usuario), escala (volumen y pico), residencia (dónde y bajo qué regulación), identidad (quién actúa, con qué credenciales, qué se audita). Son los que más deciden la plataforma.
• Registro de requisitos: comportamientos + restricciones + la regulación de origen. Permite defender la plataforma "porque la piden los requisitos" y no "porque la conocíamos".

Ciclo de vida:

1. Requirements
2. Design: plataforma, modelo, trust boundaries.
3. Build: agente, tools, prompts.
4. Test: evals, unit, integration, e2e.
5. Deploy: fijar la versión, gate de promoción con el eval.
6. Operate: costo, latencia, errores, guardrails.
7. Iterate: lo aprendido en producción vuelve a los requisitos.

Gates entre fases: no pasas de design a build sin cumplir la residencia; no promueves a producción sin pasar el eval contra el baseline. Un experimento puede saltarse fases; un despliegue regulado no.

Checkpoint 3: funcional = B (un humano aprueba el resumen antes de guardarlo) · infraestructura = C (los datos se procesan en la UE). Checkpoint 4: (a) fijar el modelo y retener el anterior = deploy · (b) gate con el eval = deploy · (c) región de datos = requirements · (d) instrumentar costo y latencia = operate · (e) elegir Bedrock por la postura de compliance = design.

4. Plataforma de despliegue y versionado

La nube del cliente suele decidir la plataforma. Las 6 plataformas:

• Identidad y residencia las resuelve la plataforma, no tu código. Bedrock y Vertex ofrecen enrutamiento regional.
• Fija la versión: los aliases (opus, sonnet) se mueven y pueden resolver a versiones distintas en cada plataforma. El ID completo es un snapshot fijo.
  • Desde Claude 4.6, el ID sin sufijo ya fija el snapshot. Antes hacía falta el sufijo de fecha (claude-haiku-4-5-20251001).
  • Versiona también el prompt y el asset, y conserva la versión anterior para poder hacer rollback.
• Promoción por eval: una parte del tráfico va a la versión nueva, se compara con el baseline fijado y se promueve o se revierte.

⚠️ Watch out: con model="opus", el alias avanzó, cambió la forma del output, el parser falló (KeyError "summary") y no había versión anterior a la que volver. Se arregló el parser, pero el despliegue siguió sin versión fijada.

Checkpoint 5 (AWS + residencia + rollback): Amazon Bedrock + identidad de AWS + ID completo fijado + retener la versión anterior.

5. Comparar plataformas: latencia, compliance y costo

• Latencia: mídela desde la región del cliente con su payload real, no desde tu laptop. Una plataforma en la región del cliente acorta el viaje; la API first-party recibe antes las features nuevas. En Bedrock, endpoint global vs regional es además el control principal de residencia y puede afectar el costo.
• Compliance: suele cerrar la discusión. Un cliente certificado en una nube no se re-certifica en otra. Para un cliente regulado, residencia y certificaciones son pasa o no pasa.
  • La API first-party puede no ofrecer residencia en la UE → normalmente Bedrock o Vertex.
  • En Foundry depende del hosting de cada modelo (los modelos alojados en Anthropic no cumplen residencia regional en la UE).
  • Plantéalo en el scoping, no en la revisión del contrato.
• Costo: las tarifas por token son similares. El total lo mueven el egress, las comisiones de plataforma y el esfuerzo de integración. Mide el costo total por llamada.

⚠️ Watch out: se eligió la plataforma "conocida" y fue rechazada en la revisión de seguridad por residencia → hubo que reconstruir todo. Fácil de construir ≠ permitido para desplegar.

Checkpoint 6: Opción 2. Volver a medir la latencia desde EU-west y elegir la plataforma cuya región cumple la residencia solo-UE (el rechazo fue por residencia, no por velocidad ni por costo).

6. Apps multi-componente y trust boundaries

• Mapea qué hace cada componente antes de conectarlos (p. ej. API → tarea de Claude Code → MCP server).
• Trust boundary: el punto donde datos o instrucciones pasan de un entorno de despliegue a otro. El contenido que trae un componente no es confiable para el siguiente → trátalo como datos. Que un componente sea confiable por sí solo no hace confiable el punto de unión.
• Least privilege en toda la app: la app está tan contenida como su punto de unión con más privilegios.
• Revisión regulada: justifica el audit logging, la residencia y los permisos en toda la app. Confirma la elegibilidad de ZDR y BAA de cada componente.
• Si un punto de unión no se puede asegurar, no lo despliegues: escálalo a un humano responsable.

⚠️ Watch out: "los 3 componentes pasan sus tests, solo los conecté". El contenido de la página del cliente pasó como instrucciones a la siguiente llamada.

Checkpoint 7: next_call(input=treat_as_data(fetched)) · MCP server con scope=least_privilege_read_only (distractores: run_as_instructions, full_access).

Tarea acumulativa (3 defectos, 3 capas)

1. Empaquetado: repo_path="/home/acme/checkout" hardcodeado → def build_agent(repo_path).
2. Despliegue y versionado: model="opus" (alias que se mueve) → ID completo de Bedrock fijado (us.anthropic.claude-opus-4-8) + retain_previous_pinned_version=True.
3. Trust boundary: next_call(input=fetched) → treat_as_data(fetched).

Además: assert eval_suite.run(model=...) >= baseline_score como gate antes de promover.

Para recordar

1. Empaqueta mientras el build está fresco: parámetros documentados + eval + audit log.
2. Un maintainer acepta lo que puede verificar: el canal correcto, código enfocado, ejemplo, test, supuestos y derechos primero.
3. Fija lo que despliegas: plataforma según la nube y el compliance del cliente; ID fijado y versión anterior conservada.
4. Mide la dimensión que decide la ubicación: latencia desde la región del cliente, compliance (pasa o no pasa) y costo total.
5. Marca cada punto de unión como frontera: el contenido traído es datos; least privilege; lo que no se puede asegurar se escala a un humano.