Revisar un conjunto de cambios asistido por IA

1354. Identidad de la lección

Módulo

3.14 — Git profesional

Lección

Revisar un conjunto de cambios asistido por IA

Tipo académico

Construcción guiada

Tipo de esquema

Práctica

Orden

2 del módulo

Tiempo estimado

45–60 minutos, incluyendo la inspección y la planificación de la recuperación

1355. Objetivo de aprendizaje

Al terminar esta lección, podrás inspeccionar un diff asistido por IA, compararlo con los límites de la tarea, identificar cambios inseguros o no relacionados, evaluar la evidencia del commit y elegir una operación de recuperación segura según el estado del repositorio.

1356. Por qué importa

El trabajo asistido por IA puede producir un cambio técnicamente plausible que aun así exceda los límites de la tarea. Una revisión profesional comprueba más que si el código parece razonable: comprueba el alcance, el comportamiento, la validación y la posibilidad de recuperar un estado seguro. Esto protege el registro de producción y evita que un commit ambiguo se convierta en la base de trabajo posterior. No se trata de desconfiar de la asistencia, sino de tomar la decisión final a partir de evidencia inspeccionable.

1357. Conocimientos previos

Debes haber completado 3.14 L1 — El historial forma parte del registro de producción. Debes poder leer un historial de commits, distinguir un commit enfocado de uno mezclado y describir una afirmación de validación. También necesitas familiaridad básica con los cambios del árbol de trabajo, los diffs, los commits y las operaciones para restaurar o revertir trabajo sin eliminar evidencia por accidente.

1358. Concepto central

Un conjunto de cambios es aceptable solamente cuando coinciden su intención, límite, implementación, evidencia y ruta de recuperación.

Revisa el cambio como una afirmación, no como un montón de archivos modificados:

1. Intención: ¿Qué se solicitó?
2. Límite: ¿Qué podía cambiar?
3. Implementación: ¿Qué cambió realmente?
4. Evidencia: ¿Qué se comprobó y qué sigue sin comprobarse?
5. Recuperación: Dado el estado del repositorio, ¿cuál es la operación segura más pequeña si la afirmación falla?

La explicación generada por la IA es contexto para la revisión, no una prueba. El diff, el comportamiento del proyecto, el registro de validación y el historial son la evidencia.

1359. Modelo mental

La revisión L-E-R

Usa esta secuencia breve para cada conjunto de cambios asistido:

Toda revisión debe terminar con una de estas decisiones:

• Aceptar: el alcance y la evidencia son suficientes.
• Separar: hay un cambio útil mezclado con trabajo no relacionado; conserva y aísla las partes.
• Corregir: el cambio pertenece al alcance, pero necesita un ajuste específico.
• Recuperar: el cambio es inseguro, inexplicable o está fuera de los límites; vuelve a un estado seguro conocido mediante una operación deliberada.

La recuperación depende del estado del repositorio

“Deshacer el cambio” no es una instrucción de recuperación suficiente. Primero determina si el trabajo afectado está sin confirmar o ya forma parte de un commit, si el historial confirmado se ha compartido y si hay trabajo actual que deba conservarse.

No trates la restauración, un commit correctivo, un commit de reversión y la revisión del historial local como operaciones intercambiables. La categoría correcta depende del estado del trabajo y de la necesidad de conservar el historial de colaboración.

1360. Ejemplo concreto

Supón que la tarea solicitada es: “Ajustar el radio de detección del guardia y actualizar la nota de configuración relacionada”. Un asistente modifica el valor de detección, cambia el nombre de una función auxiliar, añade una superposición de depuración y aplica formato a varios archivos no relacionados.

El valor de detección y la nota pueden estar dentro del alcance. El cambio de nombre exige revisar los sitios donde se llama a la función. La superposición de depuración y el formateo general están fuera de alcance, salvo que se hayan solicitado expresamente. “El juego todavía funciona” no basta para aceptar el cambio.

La revisión debe:

• registrar el límite solicitado;
• inspeccionar cada archivo modificado y cada hunk del diff;
• separar el ajuste previsto de las ediciones no relacionadas;
• comprobar los sitios de llamada afectados y el escenario de detección pertinente;
• elegir entre aceptar, separar, corregir o recuperar.

Decisión de recuperación resuelta para el conjunto mezclado

Supón que el ajuste de detección y el cambio de nombre de la función ya están en un commit compartido, mientras que la superposición de depuración y el formateo no relacionado siguen sin confirmar. El formateo incluye una nota que necesitas conservar para otra tarea.

1. Estado: Hay trabajo confirmado y compartido, además de trabajo no confirmado y mezclado.
2. Juicio sobre los límites: El ajuste puede conservarse después de validarlo; el cambio de nombre sigue siendo incierto; la superposición y el formateo quedan fuera de la tarea actual.
3. Conservación: Guarda la nota no relacionada y registra el diff actual sin confirmar antes de modificar nada. La recuperación del commit compartido no debe sobrescribir esas ediciones.
4. Operación: Después de conservar la nota, restaura únicamente las regiones no confirmadas correspondientes a la superposición y al formateo no deseados. Si la revisión demuestra que el cambio de nombre compartido es inseguro, crea un nuevo commit correctivo o de reversión que actúe sobre ese cambio; no reescribas el historial compartido.
5. Comprobaciones posteriores: Confirma que la nota conservada sigue disponible, inspecciona el diff del árbol de trabajo, revisa el historial nuevo, comprueba todos los sitios de llamada de la función y repite el escenario de detección.

La elección cambia si el commit dudoso no se ha compartido: la política del equipo podría permitir revisar el historial local, aunque un commit correctivo sigue siendo apropiado cuando importa más mantener un registro inspeccionable. En ambos casos, conserva primero el trabajo no relacionado y valida el estado resultante.

1361. Flujo de trabajo nativo de IA

Usa la IA como asistente de revisión, no como autoridad que aprueba su propio trabajo.

1. Proporciona al asistente el límite de la tarea y pídele que resuma los archivos y comportamientos previstos.
2. Compara ese resumen con la lista real de archivos modificados y con el diff.
3. Pídele una lista de supuestos, posibles violaciones de límites y comportamientos no verificados.
4. Comprueba por tu cuenta las afirmaciones de mayor riesgo en el diff, el proyecto o la ejecución.
5. Determina si el trabajo está sin confirmar o confirmado, si el commit se ha compartido y qué debe conservarse.
6. Registra la decisión y la operación de recuperación con tus propias palabras.

No le preguntes solamente: “¿Esto está bien?”. Un prompt útil especifica el límite y solicita desacuerdo:

Revisa este conjunto de cambios frente a la tarea indicada. Enumera cada archivo o comportamiento modificado que parezca estar fuera de alcance. Separa la evidencia de los supuestos, identifica las afirmaciones no comprobadas e indica qué datos sobre el estado del repositorio hacen falta antes de elegir una operación de recuperación. No apruebes el cambio.

La respuesta del asistente es una lista de comprobación candidata. No sustituye la inspección del repositorio ni del proyecto en ejecución.

1362. Flujo de trabajo de Git

Para la revisión guiada, parte de un estado limpio o documenta deliberadamente el estado inicial.

1. Identifica el commit o los cambios del árbol de trabajo que vas a revisar.
2. Inspecciona el resumen de archivos modificados antes de leer los hunks individuales.
3. Lee el diff completo, incluido el contexto cercano cuando pueda verse afectado el comportamiento.
4. Compara el diff con los límites de la tarea y con el mensaje del commit.
5. Inspecciona los sitios de llamada, la configuración y la evidencia de validación relevantes.
6. Clasifica el estado del repositorio: trabajo sin confirmar o confirmado, historial compartido o no compartido, y presencia o ausencia de trabajo que deba conservarse.
7. Decide si debes aceptar, separar, corregir o recuperar.
8. Si hace falta recuperar, nombra la categoría exacta de operación segura y las rutas o los commits afectados antes de actuar.
9. Comprueba de nuevo el historial, el árbol de trabajo, el trabajo conservado y el comportamiento pertinente.

Nunca uses un reset destructivo ni borres archivos solamente porque un cambio asistido por IA resulte confuso. Primero conserva la evidencia o establece una referencia segura conocida. Una decisión de recuperación debe describir qué se conserva, qué se modifica, por qué la operación corresponde al estado del repositorio y cómo se validará el resultado.

1363. Error común

El error común es revisar el resumen del asistente o el resultado final de la ejecución en lugar del diff completo. Un cambio puede pasar una prueba limitada y aun así introducir ediciones no relacionadas, cambiar una interfaz, debilitar un límite o dejar una ruta de recuperación poco creíble. Otro error es usar “revertir” como término genérico para cualquier forma de deshacer. Las ediciones no confirmadas, los commits locales y los commits compartidos exigen decisiones diferentes.

1364. Práctica guiada

Tarea: revisar y clasificar un conjunto de cambios asistido

Usa un conjunto pequeño de cambios de tu proyecto de práctica, o crea un ejemplo deliberadamente mezclado con al menos tres archivos modificados o tres regiones diferenciadas del diff. La tarea solicitada debe tener un límite estrecho, como cambiar un valor de configuración y su documentación.

1. Escribe la tarea en una sola frase y enumera los archivos o comportamientos incluidos explícitamente.
2. Pide a un asistente de IA que resuma el cambio previsto e identifique riesgos posibles. Guarda la respuesta en tus notas; no la trates como una aprobación.
3. Inspecciona por tu cuenta la lista de archivos modificados y el diff completo.
4. Marca cada archivo o región del diff como dentro del alcance, requiere investigación o fuera del alcance. Para cada elemento que requiera investigación, escribe qué evidencia falta.
5. Comprueba si el mensaje del commit expresa un propósito principal y una afirmación clara de validación.
6. Registra si cada cambio pertinente está sin confirmar o confirmado, si el trabajo confirmado se ha compartido y qué debe conservarse.
7. Elige una decisión: aceptar, separar, corregir o recuperar. La decisión debe abordar tanto el límite como la evidencia.
8. Escribe una especificación de recuperación que contenga:
   • la referencia segura conocida;
   • el estado del repositorio que determina la elección;
   • la categoría exacta de operación y las rutas o los commits afectados;
   • el trabajo y la evidencia que deben conservarse;
   • las comprobaciones que realizarás después.
9. Si el cambio es seguro para conservarlo, describe el commit enfocado más pequeño que debería permanecer. Si no es seguro, no ejecutes una operación destructiva sin conservar antes el trabajo y la evidencia pertinentes.

La decisión obligatoria es clasificar al menos un cambio ambiguo o mezclado y elegir una operación de recuperación que corresponda a su estado en el repositorio. No clasifiques todos los elementos como aceptables sin explicar por qué.

1365. Validación / evidencia

1366. Puntos clave

• Revisa el diff real, no solamente la explicación de la IA ni el resultado de la ejecución.
• El alcance es una propiedad técnica del conjunto de cambios, no solamente una cuestión de intención.
• Un commit enfocado necesita un propósito principal y una afirmación creíble de validación.
• La recuperación depende del estado del repositorio: trabajo sin confirmar o confirmado, historial compartido o no compartido y necesidad de conservar trabajo.
• Conserva la evidencia, elige la operación segura más pequeña y comprueba después tanto el historial como el comportamiento.
• La IA puede proponer preguntas de revisión; la responsabilidad de decidir sigue siendo del desarrollador.

1367. Siguiente lección

Continúa con Un test debe fallar por la razón correcta.

1368. Comprobación