Un desarrollador inteligente no inicia un nuevo proyecto abriendo una solicitud de extracción gigante. Se mueven a través de lluvias de ideas, discusiones con compañeros de equipo, creación de prototipos, diagramas, propuestas, ADR, MR/PR y GitOps (con un bot de revisión en cada cambio) y, cuando la escala lo exige, la arquitectura multiagente de Workstation para formar un gran equipo de desarrollo que entrega trabajo de nivel de producción rápidamente.
1. Qué significa "sabio" en un nuevo proyecto
La sabiduría es un aprendizaje barato temprano y errores raros y costosos tarde. La siguiente secuencia está ordenada de modo que cada paso reduzca el radio de explosión del siguiente:
Brainstorm → Discuss with workmates → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
Optional scale-up:
Workstation multi-agent crew (Planner / Builders / Reviewers / Ops)
with human gates on risky actions
2. Lluvia de ideas
Antes de dedicar el tiempo a otras personas, pase entre 30 y 90 minutos a solas:
- Resultado — ¿Qué debe ser cierto para el negocio cuando hayamos terminado?
- Restricciones – tiempo, cumplimiento, plataformas, habilidades, presupuesto.
- No goles – lo que la v1 no incluirá explícitamente.
- Riesgos – datos, seguridad, rendimiento, bloqueo, carga de operaciones.
- Métricas de éxito – elija dos (por ejemplo, latencia + adopción o costo + tasa de error).
Escríbelo debajo docs/ideas/. Las lluvias de ideas no escritas se evaporan.
3. Discusiones con compañeros de trabajo
Invite al círculo útil más pequeño: un par implementador, un propietario de un sistema adyacente y seguridad/SRE cuando el riesgo lo amerite.
- Cuadro de tiempo (25 a 45 minutos). Termine con decisiones o preguntas abiertas.
- Opciones de fuerza: A vs B vs aplazar – no un acuerdo vago.
- Asigne un escribano; la nota siembra la propuesta.
- Captar el malestar como riesgo para el ADR: no hay vetos silenciosos.
Los RFC asíncronos están bien si alguien cierra el ciclo.
4. Creación de prototipos
Aumente cuando la incertidumbre sea alta. Reglas sabias:
- Etiquételo como un pico; establezca una parada en el calendario (normalmente entre 1 y 3 días).
- Guárdelo en una rama desechable o
spikes/— no pulir. - Escribe diez viñetas sobre lo que aprendiste (especialmente los fracasos).
- Decida: promover, reescribir o abandonar; nunca "convertirse silenciosamente en un estímulo".
5. Diagramas
Normalmente tres bocetos son suficientes:
| Diagrama | Respuestas |
|---|---|
| Contexto (C4 L1) | ¿Quién habla con qué? ¿Límites de confianza? |
| Secuencia | Camino feliz + un camino de fracaso |
| Despliegue | Dónde corre; flujo de configuración y secretos |
Guarde Mermaid o SVG junto a la propuesta. Actualizar cuando cambien los ADR.
6. Propuestas
Mantenga el RFC breve (de 1 a 3 páginas): problema, opciones (al menos dos), recomendación, impacto (seguridad/costo/operaciones), implementación y reversión, preguntas abiertas. Cuando se apruebe, convierta la decisión en un ADR.
7. ADR: Registros de decisiones de arquitectura
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context ## Decision ## Consequences ## Alternatives considered
Mantenga los ADR en git (docs/adr/). Vincúlelos desde las relaciones públicas. Reemplazar en lugar de reescribir la historia.
8. MR y PR: la unidad de entrega
SEÑOR (Solicitud de fusión) y relaciones públicas (Pull Request) son la misma idea: un conjunto de cambios revisable.
- Pequeño (prefiera <400 líneas de diferencias significativas); una intención por cambio.
- Descripción: por qué, cómo probar, arriesgar, revertir.
- Enlaces: billete + ADR + diagrama.
- Redacte con anticipación para recibir comentarios; nunca fuerce la fusión alrededor de CI rojos o hallazgos de bots de alta gravedad sin una excepción por escrito.
## Summary ## Test plan - [ ] Unit / contract tests - [ ] Manual path … ## Risk & rollback ## References (ADR, ticket)
9. Review Bot: comentarios automáticos que protegen la producción
Un Review Bot es un primer revisor automatizado. No reemplaza a los humanos; anticipa lo aburrido y lo peligroso para que los desarrolladores dediquen tiempo al diseño y al riesgo del producto.
9.1 Qué debe comentar
- Seguridad: inyección, lagunas de autenticación, filtración de secretos, valores predeterminados inseguros
- Corrección: caminos nulos, carreras, migraciones rotas
- Pruebas: falta cobertura en nuevas sucursales
- API/contratos: cambios importantes sin cambios de versión
- Operaciones: tiempos de espera faltantes, reintentos ilimitados, escrituras no idempotentes
9.2 Cómo agiliza la vida del desarrollador
- El autor abre PR → comentarios del bot en minutos.
- El autor corrige o responde antes de preguntar a los humanos.
- Human lee el resumen del bot + se centra en la arquitectura y el radio de explosión.
- Menos rondas de liendres; Menos armas de fuego fugitivas en producción.
9.3 Política que mantiene útil el bot
- Gravedad: bloqueador / debería arreglar / liendre: los liendres no deben bloquear la fusión.
- Ignorar las rutas generadas; sintonizar los falsos positivos mensualmente.
- Requerir aprobación humana en
auth/,infra/, IAM y rutas monetarias. - Nunca permita que el robot sea el único revisor de servicios críticos para la producción.
Conecte bots SaaS (por ejemplo, CodeRabbit), Cursor Bugbot o una acción + LLM personalizada sobre la diferencia de relaciones públicas. Capa de pelusa → SAST → LLM para la postura más fuerte.
10. Mejores prácticas de GitOps para una calidad de nivel de producción
El estado deseado vive en git. Un reconciliador (Argo CD, Flux, etc.) hace que el clúster coincida. La promoción es una fusión; la reversión es una reversión.
- Separe el código de la aplicación y la configuración env (o borre
envs/dev|staging|prodsuperposiciones). - No ad hoc
kubectl applypara insistir como el camino feliz: solo vidrios rotos, auditados. - Entrega progresiva: sincronización automática de entornos inferiores; sincronización cerrada para prod.
- Resúmenes de imágenes sobre etiquetas mutables en prod.
- Política como código (OPA/Kyverno) para privilegios y registros.
- Observar después de la sincronización; practica la reversión.
La calidad del código no son sólo funciones limpias, sino también cómo el cambio entra en la producción.
11. Arquitectura multiagente de estación de trabajo: creación de excelentes equipos de desarrollo
Un único desarrollador inteligente todavía necesita influencia. La arquitectura multiagente de Workstation (paquetes de estación de trabajo Agentic AI y OpenClaw for Business donde necesita equipos de agentes incorporados o especializados) le permite construir automáticamente un equipo de desarrollo alrededor de un resumen de negocios, no de un organigrama estático.
11.1 El bucle de composición
- Breve — resultado de las partes interesadas, limitaciones, SLA.
- Componer — asignar roles a habilidades (planificador, constructor, revisor, operaciones, cumplimiento).
- Oreja — tiempo de ejecución del agente + herramientas MCP + memoria + pista de auditoría.
- Ejecutar — los agentes realizan el trabajo, lo implementan según las especificaciones/AC y realizan una pequeña revisión de cada paso.
- Revisar hasta limpiar — Bot de revisión + agentes revisores + puertas humanas.
- Barco — GitOps promueve el entorno que importa.
11.2 Mapa de roles (humano + agente)
| Role | El agente hace | El humano todavía posee |
|---|---|---|
| Planificador | Epopeyas, historias, AC de Spec | Recortes de prioridad y alcance |
| Constructores | Implementación paralela, pruebas. | Juicio de dominio en bordes duros |
| Revisores | Cumplimiento de especificaciones, clasificación del bot de revisión | Arquitectura y aprobación del producto. |
| operaciones | Sincronización de GitOps, vigilancia de SLO, reversión de borradores | Comando de puesta en marcha e incidentes |
| puerta HITL | Incrementar escrituras/gastos riesgosos | Aprobar o rechazar |
11.3 Por qué esto forma grandes equipos
- Especialización — cada agente tiene un trabajo; La calidad aumenta cuando los roles no se confunden.
- Rendimiento sin caos – constructores paralelos detrás de un único robot de revisión y especificación.
- Memoria compartida de decisiones. — El historial de ADR + Especificaciones + PR se convierte en la memoria a largo plazo del equipo.
- Las mismas puertas que los humanos. — CI, Review Bot, CODEOWNERS, GitOps: los agentes no eluden la disciplina de producción.
- Velocidad empresarial – horas para formar un equipo capaz en lugar de semanas para contratar cada pico.
11.4 Cómo se conecta al camino sabio
La lluvia de ideas y la discusión todavía suceden con los humanos. Todavía existen prototipos y diagramas. La tripulación multiagente acelera redacción de propuestas, andamiaje de ADR, segmentos de implementación, clasificación de Review Bot y promoción de GitOps – mientras que los humanos juzgan los resultados y los riesgos. Ese es el modelo de estación de trabajo: estaciones de trabajo con agentes y paquetes OpenClaw configurados para sus flujos de trabajo, no una ventana de chat que pretende ser un equipo.
12. Puertas de calidad de extremo a extremo
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI + Review Bot comments PR merge: human approve + branch protection + required checks Main: immutable artifact (image digest) GitOps: update env overlay → sync → verify Agents: Planner/Builder/Reviewer/Ops stay inside the same gates Prod: SLOs + alerts + runbook linked from ADR/PR
13. Lista de verificación inicial
- Crear
docs/ideas/,docs/architecture/,docs/adr/ - Agregar plantilla PR/MR + CODEOWNERS + protección de sucursales
- Habilitar comprobaciones previas al compromiso + CI requeridas
- Instalar el robot de revisión; ajustar filtros de ruta y gravedades
- Escriba ADR-0001: "Usamos GitOps para la implementación"
- Definir reglas de promoción ambiental y un día de juego de reversión.
- Si escala la entrega: equipo de múltiples agentes de la estación de trabajo de pie (planificador/constructores/revisores/operadores) con puertas HITL
14. Anti-patrones
- RP gigantes "WIP, por favor apruebe"
- Arquitectura solo en Slack, nunca en ADR
- Prototipo fusionado como producto sin pruebas
- Deshabilitar el bot de revisión porque molesta
- Agentes con acceso de escritura y sin puerta humana
- Revisión para impulsar fuera de GitOps sin plan de reversión
15. Cierre
Un desarrollador inteligente trata un nuevo proyecto como una secuencia de artefactos de aprendizaje (notas, diagramas, propuestas, ADR) y luego lo entrega a través de pequeños MR/PR observados por un Review Bot y promovidos por GitOps. La arquitectura multiagente de Workstation extiende esa sabiduría a un equipo de desarrollo completo: agentes especializados, especificaciones compartidas, juicio humano donde importa y puertas de nivel de producción en todos los caminos de la vida. Así es como la calidad del código se mantiene optimizada para la producción mientras el negocio avanza rápidamente.
Publicado por Puesto de trabajo.
