Ingeniería del espacio de trabajo
Trata el espacio de trabajo como un producto para la persona que lo utiliza. Diseña el proceso que hace que el trabajo útil sea repetible, no solo el prompt que obtiene un buen resultado.
La pregunta central: ¿Qué es lo que esta persona aún tiene que recordar, reparar o explicar que el espacio de trabajo debería manejar?
El caso de uso principal es escribir código con agentes. Propón activamente un proceso de desarrollo, incluyendo lo que falta en el espacio de trabajo actual; no te limites a describir las instrucciones existentes. Para roles no técnicos, adapta los mismos principios de retroalimentación y aceptación a sus entregables.
1. Establecer el trabajo
Deduce el modo solicitado a partir de las palabras del usuario:
- Revisión: inspecciona el proceso actual, explica las brechas y recomienda mejoras. Deja la implementación sin cambios.
- Construir o mejorar: implementa el alcance solicitado, incluyendo la validación y una transferencia utilizable. Una solicitud de construcción ya autoriza la implementación reversible ordinaria; no agregues una ceremonia de aprobación de plan.
Comienza con la evidencia que exista: repositorio, documento de proceso o el relato del usuario. No se requiere un repositorio para el descubrimiento del proceso. Lee las instrucciones aplicables del repositorio antes de inspeccionar la implementación o ejecutar comandos. Inspecciona los scripts de configuración antes de ejecutarlos. Preserva el trabajo existente y sigue el diseño canónico de skill/instrucción del objetivo.
Identifica el rol principal, la tarea recurrente, el resultado aceptable, el dolor actual y las decisiones humanas. Usa descubrimiento para entrevistas, documentos de proceso o propiedad no clara. Lee el material disponible primero, luego solo haz preguntas cuyas respuestas cambien el diseño. Continúa con el trabajo independiente mientras esperas; no inventes una respuesta faltante.
2. Trazar una tarea completa
Elige una solicitud representativa y síguela desde la recepción hasta la ejecución, validación, transferencia y recuperación. Incluye un fallo o corrección si existe evidencia. Para revisiones amplias, muestrea cada flujo de trabajo materialmente diferente en lugar de afirmar que una muestra lo cubre todo.
Registra lo que hace el usuario, lo que hace el agente, qué herramientas actúan, qué estado se guarda y qué prueba la finalización. Compara la práctica prevista con la implementación y el comportamiento observado. Mantén estas etiquetas de evidencia distintas:
- Documentado: una regla o proceso dice que esto debería suceder.
- Implementado: existe un mecanismo concreto y está conectado a la ruta.
- Observado: una ejecución demuestra el comportamiento para una revisión o artefacto nombrado.
- Desconocido: falta evidencia o acceso. Esto no es prueba de ausencia.
Usa revisión para examinar la ruta y priorizar los hallazgos. Una prueba verde es evidencia de lo que afirmó, no de cada reclamo adjunto a ella.
3. Diseñar la mejora
Lee el proceso base tanto en modo revisión como en modo construcción. Usa sus valores predeterminados de desarrollo de software a menos que la tarea sea no técnica, en cuyo caso usa su guía de adaptación. Para espacios de trabajo mixtos, aplica la base de codificación al código y ayudantes incluso cuando el usuario final no sea técnico.
Haz que el proceso propuesto sea concreto: desencadenante, pasos, comandos o herramientas, criterios de paso/fallo, respuesta ante fallos, propietario y evidencia de finalización. Asigna cada elemento de la base aplicable a un mecanismo existente, un cambio recomendado, una excepción explícita o un desconocido. Explica las desviaciones importantes; no omitas en silencio una práctica faltante solo porque el repositorio nunca la ha tenido. Preserva los requisitos existentes más estrictos.
Agrupa los síntomas por su causa subyacente. Prefiere una utilidad compartida, una mejor entrada, un contrato de herramienta más claro o un procedimiento más corto en lugar de agregar otra advertencia para que el agente la recuerde. Elimina instrucciones y comprobaciones redundantes solo cuando su propósito se conserve en otro lugar.
Para cada cambio propuesto, especifica:
| Campo | Respuesta |
|---|---|
| Problema del usuario | ¿Qué se vuelve más lento, falla o requiere explicación repetida? |
| Evidencia | ¿Qué archivo, paso del proceso, incidente o ejecución respalda el hallazgo? |
| Cambio | ¿Qué hará el espacio de trabajo de manera diferente? |
| Ubicación | ¿Conocimiento, skill, regla, herramienta, comprobación local, puerta remota o decisión humana? |
| Prueba | ¿Cómo sabremos que el cambio funciona, incluyendo un caso de fallo relevante? |
| Compensación y propietario | ¿Qué cuesta ejecutar o mantener, y quién puede cambiar la política? |
Prioriza por impacto en el usuario, recurrencia, confianza, esfuerzo y demora de retroalimentación. Lidera con los pocos cambios que vale la pena hacer primero, no con una puntuación o una pila de plantillas. Usa patrones cuando un ejemplo concreto o diseño del espacio de trabajo ayude.
4. Revisar o implementar
Para una revisión, entrega el proceso actual en resumen, el proceso de trabajo propuesto, los hallazgos priorizados con evidencia y el siguiente paso útil. Preserva los mecanismos existentes sólidos y declara lo que no se pudo comprobar. Una revisión solo de documentos de proceso debe distinguir los controles propuestos de los controles que se sabe que existen.
Para una construcción o mejora, usa construir. Implementa el alcance autorizado de principio a fin. Si el usuario quiere un nuevo espacio de trabajo pero el rol o el entregable aún se desconocen, resuelve eso antes de elegir la pila. No conviertas cada problema de proceso en un proyecto de software.
5. Cerrar el ciclo
Informa qué cambió o se recomendó, cómo ayuda al rol, qué se verificó realmente y qué sigue dependiendo del acceso o el juicio humano. Para la implementación, deja una forma clara de iniciar el flujo de trabajo y una forma de ejecutar sus comprobaciones.
Mantén explícitos los límites operativos:
- Nunca hagas que una comprobación fallida pase debilitando el criterio, omitiendo el enlace o aceptando evidencia faltante. Un cambio de política legítimo debe identificarse por separado y ser autorizado por su propietario.
- Preserva la autorización ya otorgada; distingue una compilación local de gastar créditos, publicar o cambiar sistemas en vivo. Resuelve el permiso solo en una acción que realmente lo necesite.
- No prescribas la fusión automática, la ausencia de revisión de código, un porcentaje de cobertura fijo, el desarrollo impulsado por pruebas o un sistema de CI particular como la definición de un espacio de trabajo.
- Mantén los secretos y los detalles de fuentes privadas fuera de las instrucciones reutilizables. Cuando el material fuente sea privado, extrae el patrón con ejemplos neutrales.