Rechazar la reescritura del sistema vecino

1089. Identidad de la lección

Módulo

3.5 — Acoplamiento

Lección

Rechazar la reescritura del sistema vecino

Tipo académico

Flujo de trabajo

Tipo de esquema

Mixto

Orden

Lección 2 del módulo

Tiempo estimado

45–60 minutos, incluida la práctica

Esta lección entrena una decisión de revisión: aceptar, reducir o rechazar un diff generado por IA cuando el cambio solicitado tiene un límite definido.

1090. Objetivo de aprendizaje

Al terminar esta lección, podrás aceptar, reducir o rechazar un diff generado por IA comparando la superficie modificada, las dependencias y las evidencias con el límite del encargo.

1091. Por qué importa

La IA suele interpretar un cambio local como permiso para reorganizar sistemas cercanos. Esa expansión puede aumentar el acoplamiento aunque la petición original sea pequeña. Una reescritura innecesaria puede alterar la responsabilidad, los tiempos o el flujo de datos de los que ya depende otro sistema. Revisa el cambio como una decisión sobre límites, no solo como una decisión sobre calidad del código.

1092. Conocimientos previos

Debes poder identificar riesgos de acoplamiento, distinguir la responsabilidad de un sistema de la de un sistema vecino y explicar el coste de un cambio. Esta lección depende directamente de 3.5 — Acoplamiento: el acoplamiento tiene un coste de cambio.

También necesitas experiencia básica para leer un diff generado por IA y comparar el comportamiento solicitado con evidencias observables.

1093. Concepto central

Controlar el alcance significa conservar el límite solicitado salvo que las evidencias exijan ampliarlo.

Un cambio útil no es automáticamente un cambio justificado. Compara con la petición cada archivo, función, flujo de datos, interfaz pública y decisión de responsabilidad que se haya modificado. Si un cambio pertenece a un sistema vecino, pero no es necesario para cumplir el encargo, pide a la IA que lo elimine o rechaza el diff.

Usa tres decisiones:

1. Aceptar — el diff se mantiene dentro del límite solicitado y cuenta con evidencias suficientes.
2. Reducir — una parte del diff es útil, pero deben eliminarse los cambios no relacionados o los que desplazan responsabilidades.
3. Rechazar — los cambios problemáticos no pueden aislarse ni justificarse con seguridad, por lo que no debe aceptarse el diff completo.

Tocar un sistema vecino no siempre es incorrecto. Un cambio adyacente justificado puede usar un contrato existente sin trasladar responsabilidades. Por ejemplo, una interfaz puede mostrar un resultado producido por un sistema de juego mientras este último sigue siendo la autoridad sobre dicho resultado.

1094. Modelo de revisión de límites

Usa esta secuencia:

Límite solicitado → Inventario de la superficie modificada → Clasificación y justificación → Evidencias → Aceptar, reducir o rechazar

No uses “el código queda más limpio” como evidencia de que la expansión era necesaria. La limpieza puede ser una tarea posterior válida, pero no pertenece automáticamente al diff actual.

1095. Ejemplo concreto

Supón que la petición es:

Añade un temporizador de reutilización (cooldown) al comando de interacción. El sistema de interacción debe ser responsable del temporizador. No cambies las reglas de progresión.

Un diff generado por IA hace cuatro cosas:

• Añade un campo de temporizador al sistema de interacción.
• Bloquea el comando mientras el temporizador está activo.
• Cambia el nombre de campos de progresión por motivos de consistencia.
• Traslada al sistema de interacción la comprobación del umbral de progresión.

Los dos primeros cambios están dentro de la petición. El cambio de nombres es una expansión no relacionada. Trasladar la comprobación cambia la responsabilidad y crea acoplamiento de conocimiento: el sistema de interacción pasa a conocer una regla de progresión que pertenece a otro sistema.

No aceptes todo el diff solo porque el temporizador funcione. Redúcelo al comportamiento solicitado, elimina el cambio de nombres y el traslado del umbral, y comprueba que el sistema de progresión sigue siendo responsable de evaluar su propio umbral.

1096. Flujo de trabajo con IA

Usa la IA como colaboradora de implementación con un alcance acotado, no como autoridad para definirlo.

1. Declara el límite. Indica el comportamiento solicitado, el sistema responsable, los contratos permitidos y los objetivos excluidos.
2. Registra la rama o el punto de control del intento acotado. Identifica dónde se encuentra el intento para no incluir trabajo ajeno en la revisión.
3. Pide un plan antes de editar. Solicita la lista de archivos, responsabilidades, contratos y comprobaciones que la IA espera tocar.
4. Inventa toda la superficie modificada. Registra cada elemento cambiado antes de decidir si pertenece al encargo.
5. Clasifica cada elemento. Márcalo como requerido, adyacente justificado, productor de evidencia, no relacionado o desplazamiento de responsabilidad.
6. Acota el seguimiento. Indica con precisión qué debe conservarse, eliminarse y preservarse.
7. Ejecuta comprobaciones específicas. Verifica el comportamiento solicitado y al menos un comportamiento vecino que deba mantenerse.
8. Registra la decisión. Indica aceptar, reducir o rechazar y cita el inventario, el razonamiento, las comprobaciones y el punto de control del intento.

Puedes usar instrucciones como estas:

• “Reformula el límite solicitado, el sistema responsable, el contrato permitido y los objetivos excluidos antes de editar.”
• “Para cada cambio propuesto, identifica el requisito o la necesidad de evidencia que satisface.”
• “Revisa este diff para detectar desplazamientos de responsabilidad, nuevo acoplamiento de conocimiento y expansiones no relacionadas.”
• “Conserva solo los cambios enumerados y preserva el comportamiento vecino indicado.”

La explicación de la IA es una afirmación que debes comprobar, no una evidencia por sí misma.

1097. Errores comunes

Un error habitual es aceptar un diff amplio porque parece más completo o elegante desde el punto de vista arquitectónico. Un diff grande puede ocultar un traslado de responsabilidad aunque el comportamiento solicitado funcione. “La IA ya tocó ese archivo” no justifica ampliar la tarea.

El error opuesto consiste en rechazar cualquier cambio en un sistema vecino. Una implementación que respeta los límites puede tocar legítimamente un sistema adyacente mediante un contrato existente. Comprueba si la responsabilidad y la autoridad permanecen estables, si el cambio adyacente es necesario y si existen evidencias específicas que lo respalden.

1098. Práctica guiada

Revisa este diff hipotético. La petición es:

Añade al sistema de inventario un peso máximo de carga de 12 kilogramos. El sistema de inventario es responsable del límite. Mantén sin cambios el cálculo de recompensas de la economía.

En el diff compacto, cada signo + indica una línea añadida. Expresado en prosa, el diff añade al inventario un límite de peso y una regla de rechazo, cambia la representación y los nombres de las recompensas, traslada la comprobación del peso a la economía y añade un evento de finalización de recompensa.

inventory.ts
+ añade maxCarryWeightKg = 12
+ rechaza adiciones cuando currentWeightKg + itemWeightKg > maxCarryWeightKg

reward.ts
+ convierte los valores de recompensa de enteros a números de coma flotante
+ cambia rewardAmount por payout

economy.ts
+ traslada la comprobación del peso al cálculo de recompensas
+ añade un evento nuevo para que el inventario escuche la finalización de la recompensa

Completa la revisión antes de leer la decisión de referencia:

1. Expresa el límite solicitado en una frase.
2. Inventa cada línea modificada o grupo lógico.
3. Clasifica cada elemento como requerido, productor de evidencia, adyacente justificado, no relacionado o desplazamiento de responsabilidad.
4. Elige aceptar, reducir o rechazar para el diff completo.
5. Escribe una instrucción de seguimiento acotada.
6. Especifica una comprobación para la regla de peso y otra que demuestre que el cálculo de recompensas no cambió.

Decisión de referencia

Una decisión sólida es reducir. Conserva maxCarryWeightKg y la regla de rechazo controlada por el inventario. Elimina el cambio de representación de recompensas, el cambio de nombre, el traslado de la comprobación y el evento nuevo, salvo que otra petición los justifique. Comprueba un caso límite de exactamente 12 kilogramos, un intento que supere el límite y un cálculo representativo de recompensa que deba permanecer igual.

1099. Evaluación práctica puntuada

Completa Revisión práctica de un diff: preservar el límite de responsabilidad. Utiliza un diff nuevo que contiene:

• un cambio requerido en el sistema responsable,
• un cambio justificado en un sistema adyacente mediante un contrato de resultados existente,
• una prueba específica que produce evidencias, y
• un traslado perjudicial de la autoridad de decisión a un controlador vecino.

Entrega un inventario completo de la superficie modificada, la clasificación y justificación de cada elemento, una decisión de aceptar, reducir o rechazar, una instrucción acotada para la IA y comprobaciones del comportamiento solicitado y del comportamiento que debe preservarse. La evaluación utiliza la rúbrica de revisión de diffs del módulo. No consultes la referencia posterior a la entrega hasta haber fijado tu propia decisión.

1100. Validación y evidencias

1101. Ideas clave

• Revisa un diff de IA comparándolo con la petición, no con su aparente grado de completitud.
• Inventa todos los elementos modificados antes de decidir.
• Una superficie adicional necesita justificación, aunque un cambio adyacente mediante un contrato existente puede ser válido.
• Acepta solo cuando el alcance y las evidencias sean suficientes.
• Reduce el trabajo útil cuando esté mezclado con cambios no relacionados o que trasladen responsabilidades.
• Rechaza cuando los cambios perjudiciales no puedan aislarse ni justificarse con seguridad.

1102. Próxima lección

Continúa con 3.6 — Renderizado 3D. El mismo análisis de responsabilidades y límites se aplicará después al estado de simulación, los datos de renderizado y los objetos renderizados a lo largo de un recorrido de renderizado 3D.

1103. Comprobación