Cómo las herramientas de programación con IA cambian código ajeno

El autocompletado, los asistentes y los agentes pueden producir una función que parece plausible. Esa semejanza superficial ha llevado a proveedores y equipos de ingeniería a usar un mismo nombre para tres modelos operativos distintos. El nombre oculta lo que importa: qué puede observar la herramienta, qué puede cambiar y qué pruebas reúne antes de declarar que el trabajo ha terminado.

En una base de código conocida, esas diferencias afectan a la velocidad. En un sistema cuyos autores ya no están, determinan si se conserva un comportamiento que nadie recordó documentar. Una herramienta de autocompletado predice texto cerca del cursor. Un asistente responde a partir de un contexto limitado. Un agente elige acciones, observa sus resultados y continúa. Tratar una como si fuera otra genera una confianza falsa mucho antes de provocar un error del compilador.

Cómo predice el autocompletado la siguiente edición local

El autocompletado propone texto a partir del código que rodea al cursor y del contexto adicional del repositorio que suministre su entorno. Su unidad natural de trabajo es el siguiente token, línea o bloque pequeño. Aunque una sugerencia abarque una función, la interacción sigue siendo predictiva: la herramienta ofrece texto y el desarrollador decide si lo acepta.

Este modelo es excelente cuando la intención ya está en el archivo actual. Repetir un patrón de gestión de errores, completar un switch sobre una enum conocida, construir una tabla de pruebas a partir de casos contiguos o escribir otro método que siga una interfaz visible son tareas adecuadas. El desarrollador conserva el diseño en la cabeza. La herramienta evita teclear y recuerda la sintaxis.

El Language Server Protocol establece aquí una distinción útil. Su solicitud de compleción incluye una posición del documento y puede incluir un carácter o tipo de activación. El protocolo no define una misión como «sustituir esta capa de almacenamiento» ni un ciclo de pruebas para demostrar que el reemplazo funciona. Un producto puede enriquecer la compleción con fragmentos indexados del repositorio, pero la interacción sigue terminando en una sugerencia. Recuperar más contenido puede mejorar la conjetura sin convertirla en una investigación.

El autocompletado deja de ser útil cuando la corrección depende de hechos que quedan fuera del entorno facilitado. Un párrafo COBOL puede actualizar un campo cuyo formato procede de un copybook, mientras JCL selecciona otro conjunto de datos al cierre del mes. Un controlador de eventos VB6 puede parecer inutilizado hasta que un archivo de formulario lo enlaza por su nombre. Un procedimiento PL/SQL puede depender de una variable de paquete inicializada por una llamada anterior. El dato que falta suele tener sintaxis válida y no deja ninguna señal visible en el punto de edición.

Observe el gesto de aceptación. Pulsar Tab significa «inserta estos caracteres», no «he demostrado que este comportamiento es seguro». Los equipos se meten en problemas cuando la facilidad física de aceptar sustituye silenciosamente a la revisión. Una compleción larga merece más recelo, porque su superficie pulida puede ocultar más supuestos.

Cómo trabaja un asistente dentro de la conversación facilitada

Un asistente de programación responde a una petición con el material incluido en su contexto: código seleccionado, archivos abiertos, fragmentos recuperados, diagnósticos, instrucciones y turnos anteriores. Su unidad natural es la conversación. Puede explicar una rutina, comparar diseños, redactar un parche o razonar sobre un error con más espacio que el autocompletado.

Ese espacio adicional cambia la calidad del trabajo. Puede pedir al asistente que siga un valor por cuatro funciones, identifique una invariante implícita o explique por qué una refactorización propuesta cambia los límites de una transacción. Puede cuestionar su primera respuesta y añadir el archivo que no vio. Esto resulta útil para explorar, sobre todo cuando un desarrollador sigue siendo responsable de elegir las pruebas.

El límite se pasa por alto fácilmente porque las interfaces de chat hablan con fluidez sobre archivos que nunca han abierto. Si el asistente afirma: «Esta función solo la llama el importador por lotes», la afirmación puede ser una deducción del fragmento pegado y no el resultado de buscar en el repositorio. Pregunte qué inspeccionó. Una respuesta sólida debe nombrar los puntos de llamada, la configuración, los enlaces generados o las pruebas de ejecución que respaldan la conclusión. Si no puede hacerlo, trate la afirmación como una hipótesis.

Las ventanas de contexto no resuelven la selección del contexto. Un millón de líneas pueden encajar mal aunque un modelo acepte una entrada enorme. Los árboles de código contienen código generado, versiones duplicadas, definiciones de base de datos, scripts de despliegue, formatos binarios y pruebas con distinta autoridad. Añadir más tokens al prompt no indica al asistente qué copybook está activo en producción ni cuál de dos cálculos casi idénticos es el exigido por la normativa.

Utilice un asistente para convertir la incertidumbre en preguntas explícitas. Pídale que enumere los supuestos de un parche, nombre archivos que podrían refutarlos y describa la prueba de comportamiento que espera superar. Ese resultado da al revisor algo concreto que inspeccionar. No pida puntuaciones de confianza. Un porcentaje que suena preciso no comparte ninguna calibración y no añade pruebas.

Cómo cambia un agente el repositorio con un ciclo de acciones

Un agente de programación puede seleccionar y ejecutar acciones y después usar los resultados para elegir la siguiente. Puede buscar en el árbol, abrir archivos, editar varios módulos, ejecutar un compilador, lanzar pruebas, examinar fallos y revisar el parche. Su unidad natural es una tarea con una condición de parada, no una única respuesta.

El ciclo importa más que la ventana de chat. Un agente útil hace algo parecido a esto:

1. Determina el estado del repositorio y las instrucciones aplicables.
2. Busca definiciones, llamadores, configuración, pruebas y enlaces generados.
3. Realiza un cambio acotado en una rama o un worktree aislado.
4. Ejecuta las comprobaciones que podrían refutar el cambio.
5. Inspecciona el diff e informa de la incertidumbre restante.

Cada observación puede redirigir el trabajo. Una prueba fallida puede revelar una regla de redondeo no documentada. Un error del compilador puede descubrir un build tag que selecciona otra implementación. Una búsqueda puede encontrar un segundo lenguaje que llama a la misma rutina de base de datos. El agente puede seguir estas ramificaciones sin esperar a que una persona pegue el archivo siguiente.

La capacidad de actuar no implica autonomía sin límites. La escritura de archivos, los comandos de shell, el acceso a la red, las credenciales, los permisos de despliegue y las reglas de aprobación son capacidades independientes. Una herramienta capaz de editar el árbol pero no de ejecutar pruebas tiene un ciclo de pruebas más corto. Otra capaz de ejecutar cualquier comando en producción tiene un modelo de permisos peligroso. Llamar «agentes» a ambas no dice casi nada a un responsable de ingeniería.

También hay que examinar la condición de parada. «Las pruebas pasan» solo es suficiente si cubren el comportamiento en riesgo. «La compilación termina bien» demuestra restricciones de tipos y enlaces, no equivalencia empresarial. El agente debe detenerse porque ha cumplido una condición de aceptación explícita y ha agotado las comprobaciones acordadas, no porque se haya quedado sin acciones obvias o haya producido un diff ordenado.

En sistemas desconocidos, el contexto ausente es el principal riesgo

En código desconocido, el mayor riesgo no suele ser generar la sintaxis de sustitución. Es descubrir el contrato de comportamiento que atraviesa archivos fuente, control de trabajos, datos, operaciones y hábitos de los usuarios. Los autores originales suelen codificar ese contrato en lugares que una búsqueda moderna del repositorio clasifica mal.

Pensemos en un proceso nocturno de facturación. Una rutina de cálculo se entiende bien de forma aislada, así que un asistente la reescribe en un lenguaje moderno y sus pruebas unitarias pasan. El comportamiento en producción también depende de un código de condición JCL que omite un paso tras una entrada parcial, de un registro de ancho fijo donde un importe en blanco no equivale a cero y de un procedimiento de repetición del operador que conserva un archivo intermedio. Ninguno de esos hechos tiene por qué aparecer en la rutina. Una reescritura localmente fiel puede cobrar dos veces durante una repetición.

Aquí el sector confunde dos clases de contexto. El contexto de código es el material que la herramienta puede leer: código, esquemas, archivos de compilación, tickets y pruebas. El contexto operativo demuestra lo que el sistema hace realmente: peticiones de producción, entradas por lotes, salidas, tiempos, efectos secundarios, recuperación de fallos y decisiones de operadores. Más contexto de código no recupera automáticamente el contexto operativo. La consecuencia es directa: comprender un repositorio puede ayudar a una migración, pero por sí solo no demuestra la paridad del comportamiento.

Los sistemas heredados añaden enlaces entre lenguajes. COBOL llama a ensamblador o a procedimientos de base de datos. Los programas RPG dependen de comandos CL y archivos descritos externamente. Una página Classic ASP invoca componentes COM creados en VB6. Un libro de Excel llama a una consulta de Access que llama a un procedimiento almacenado. Una herramienta que solo indexa el lenguaje indicado en el ticket produce un mapa limpio con carreteras ausentes.

Antes de cambiar un sistema así, escriba el límite de las pruebas. ¿Qué repositorios están incluidos? ¿Qué planificadores, esquemas, formatos de datos y trazas de ejecución están disponibles? ¿Qué llamadas externas se simularán? ¿Qué acciones de los operadores quedan fuera de observación? No es papeleo del proyecto. Indica qué afirmaciones puede sostener la herramienta y cuáles todavía requieren una persona que conozca la producción.

La paridad de comportamiento necesita un oráculo externo al código nuevo

Una reescritura debe juzgarse frente al comportamiento observado, no por lo razonable que parezca la nueva implementación. El oráculo más seguro es independiente del código generado: entradas registradas que se envían a ambas versiones, con salidas y efectos secundarios comparados según reglas de normalización explícitas.

Un pequeño arnés de paridad puede empezar con un manifiesto que declare qué se considera igual:

{
  "case": "month_end_partial_input",
  "input": "fixtures/partial.dat",
  "compare": ["stdout", "records", "exit_code"],
  "ignore": ["run_id", "processed_at"]
}

Después ejecute las implementaciones antigua y nueva desde un estado limpio y conserve resultados legibles por máquinas:

case                         old  new  records  result
month_end_partial_input      04   04   1827     PASS
blank_amount_field           00   00   19       PASS
operator_rerun_after_step_3  00   08   641      FAIL

La fila fallida es más útil que una revisión de código confiada. Da al equipo una entrada reproducible, el primer efecto divergente y un punto desde el que investigar. La comparación debe cubrir datos devueltos, escrituras en la base de datos, mensajes emitidos, archivos, códigos de salida y orden cuando los consumidores lo observan. Normalice solo valores que el contrato permita variar, como identificadores de ejecución generados. Una lista de exclusión demasiado amplia hace que cualquier implementación parezca correcta.

El tráfico de producción registrado tiene lagunas. Pueden faltar rutas de error infrecuentes, los campos sensibles pueden exigir un tratamiento controlado y los trabajos por lotes pueden depender del reloj o del entorno. Añada casos diseñados para límites, entradas incorrectas, reintentos y recuperación. Mantenga el ejecutable antiguo disponible en un arnés aislado cuando las licencias y el acceso a la plataforma lo permitan. Si no existe un oráculo independiente, dígalo claramente y reduzca el alcance del cambio automático.

No recomiendo usar pruebas escritas por el modelo como única suite de aceptación. La recomendación es popular porque el modelo puede producir código y pruebas de una vez, y la compilación en verde parece completa. Ambos artefactos pueden compartir el mismo supuesto erróneo. Las pruebas generadas ayudan a expresar reglas conocidas; no descubren de manera independiente las reglas que la generación pasó por alto.

El trabajo de paridad falla cuando los equipos comparan solo el valor devuelto por la ruta feliz. Los cambios de estado suelen escapar por canales que el nuevo diseño pretende eliminar: un archivo temporal consumido por otro trabajo, un código de estado comprobado por JCL, una fila de base de datos escrita antes de un error o un informe ordenado como esperan los operadores. Inventaríe los efectos observables desde fuera. Si un consumidor puede distinguir dos ejecuciones, el arnés debe comparar esa diferencia o documentar por qué puede cambiarla el nuevo contrato.

El tiempo merece una fixture propia. Los programas antiguos suelen consultar el reloj más de una vez, derivar fechas empresariales de variables del planificador o usar la medianoche local como límite de procesamiento. Congele el tiempo cuando la plataforma lo permita y registre los valores que suministra el planificador. Haga lo mismo con valores aleatorios, generadores de secuencias, configuración regional, codificación y variables de entorno. Sin entradas controladas, el informe de diferencias se llena de ruido y los revisores empiezan a ignorar fallos que pueden incluir el importante.

Comparar bases de datos exige algo más que volcar las tablas finales. Capture los límites de transacción y puntos de fallo cuando los llamadores puedan observarlos. Dos implementaciones pueden acabar con filas idénticas tras el éxito y comportarse de forma distinta cuando falla la tercera escritura. Ejecute casos de fallo que interrumpan el trabajo en puntos controlados y compare filas confirmadas, marcadores de reintento, bloqueos, mensajes emitidos y el resultado del procedimiento documentado de repetición. Es un trabajo tedioso, pero convierte la vaga instrucción «conservar el comportamiento» en pruebas que un ingeniero puede debatir.

Las reglas de normalización deben revisarse junto al arnés. Una regla como «ignorar todas las marcas de tiempo» suele ser demasiado amplia; puede ocultar una fecha de liquidación desplazada al periodo equivocado. Prefiera reglas por campo con una justificación, como ignorar un identificador de traza generado mientras se compara exactamente la marca de tiempo con significado empresarial. Cuando cambie una regla, vuelva a ejecutar casos anteriores y registre qué diferencias desaparecen. La configuración de exclusiones forma parte de la especificación de la migración, no de la limpieza.

El sistema antiguo también puede contradecirse. Las grabaciones de producción pueden contener un defecto aceptado, una corrección manual no documentada o comportamientos que varían según el despliegue. No deje que el agente elija en silencio la versión más cómoda. Clasifique cada discrepancia como comportamiento que conservar, defecto que reparar mediante otra decisión, diferencia permitida u observación sin resolver. El propietario del proceso empresarial debe aprobar la segunda y tercera categorías. De lo contrario, la reescritura puede introducir cambios de política a través de una revisión técnica.

Un resultado de paridad debe ser reproducible por alguien que no ejecutó la tarea original. Conserve la revisión del código, entradas de compilación, identidad de fixtures, descripción del entorno, versión de normalización, línea de comandos y artefactos de salida. Calcule el hash de fixtures grandes o sensibles cuando no convenga copiarlas, pero mantenga una ruta controlada hacia los originales. Oculte datos mediante un proceso definido en vez de editar las fixtures de manera informal, porque el enmascaramiento puede cambiar longitudes de campo, conjuntos de caracteres, sumas de comprobación y rutas lógicas.

El comportamiento dinámico necesita otro método de descubrimiento distinto de los grafos de llamadas estáticos. La búsqueda encuentra un nombre de función directo, pero puede perder reflexión, despacho basado en cadenas, callbacks de base de datos, registro de plugins, invocaciones del planificador y nombres construidos desde la configuración. Combine la búsqueda de código con metadatos de compilación y observación en ejecución. En un sistema que permita trazas, registre módulos cargados, trabajos ejecutados, endpoints llamados, archivos abiertos y rutinas de base de datos para casos representativos. La traza no sustituye la lectura del código; muestra qué partes de un mapa amplio participan en el comportamiento observado.

Las afirmaciones de cobertura deben nombrar el denominador. Decir que un agente «leyó el repositorio» puede significar que enumeró todos los archivos, incorporó texto seleccionado, analizó lenguajes compatibles o construyó un grafo de dependencias entre lenguajes. Son acciones distintas. Pida recuentos por tipo de archivo, exclusiones explícitas, errores de análisis, símbolos sin resolver y enlaces deducidos de la configuración. Un informe breve de exclusiones inspira más confianza que una afirmación general de comprensión completa.

Por último, pruebe el propio arnés con mutaciones deliberadas. Cambie un campo de comparación, invierta una salida ordenada, modifique un código de salida y suprima un efecto secundario. Cada mutación debe producir un fallo claro. Si el arnés sigue en verde, no es un oráculo para ese comportamiento. Los equipos revisan el código de aplicación y tratan la infraestructura de pruebas como neutral; en una reescritura generada, la maquinaria de comparación merece como mínimo el mismo recelo que el código que juzga.

El autocompletado gana cuando el desarrollador ya posee la intención

El autocompletado suele ser la mejor herramienta para un cambio acotado y entendido, porque mantiene bajos la latencia y el trámite. Si conoce el contrato, ve los tipos relevantes y revisará cada inserción, un ciclo de acciones añade trabajo sin encontrar muchas pruebas nuevas.

Una buena tarea de compleción tiene un radio de revisión pequeño. Algunos ejemplos son convertir aserciones repetidas en una tabla, añadir otra rama de analizador siguiendo los casos contiguos, escribir una llamada conocida a una API o completar código de serialización a partir de un esquema visible. El desarrollador puede rechazar una sugerencia errónea en segundos porque ya sabe cómo es el resultado correcto.

Fije un límite práctico. Cuando tenga que preguntar si otro archivo controla el comportamiento, deje de aceptar compleciones grandes y busque. Cuando la edición cruce un límite de persistencia, permisos, lenguaje o trabajo asíncrono, pase a un asistente para analizar o a un agente para investigar. El cambio depende de la incertidumbre y del radio de impacto, no del número de líneas. Un cambio de una línea en un formato de registro puede ser más arriesgado que una fixture de prueba de cien líneas.

Revise el resultado como código de un compañero rápido que no asistió a la reunión de diseño. Compruebe rutas de error, propiedad de recursos, conversiones numéricas, codificación y supuestos de concurrencia. No premie a la herramienta por imitar el estilo local si este contiene un fallo. La repetición es precisamente donde el autocompletado puede reproducir un mal patrón con eficiencia.

Desactive o limite el autocompletado donde una revelación o inserción accidental sea inaceptable. El código regulado, los secretos en configuraciones cercanas, los textos legales generados y las consolas de producción merecen reglas explícitas. La cuestión no es si el proveedor del modelo resulta fiable en general. Es qué datos envía el entorno, dónde ocurre la inferencia, qué retiene y qué controles puede aplicar su organización.

Los asistentes son mejores cuando se puede acotar la pregunta

Un asistente funciona bien cuando un desarrollador puede definir el conjunto de pruebas y evaluar la respuesta sin conceder acceso de escritura. Encaja con la arqueología de código, comparación de diseños, revisión de parches, explicación de consultas y conversión de una observación de incidente en casos de prueba.

Formule una pregunta acotada con pruebas nombradas. En vez de «explica este subsistema», pida: «Usando la definición del trabajo, estos dos copybooks y los tres llamadores, explica cuándo CUSTOMER-STATUS cambia de H a A. Cita el archivo y símbolo de cada transición y enumera cualquier ruta que no puedas resolver». La respuesta todavía puede ser errónea, pero el formato solicitado hace visibles los saltos sin respaldo.

El asistente debe separar observación, inferencia y propuesta. La observación dice que un llamador pasa un campo en blanco. La inferencia dice que probablemente representa un importe ausente porque dos pruebas esperan ese resultado. La propuesta dice que el nuevo analizador debería asignar los blancos a un valor opcional explícito. Mezclar esas afirmaciones convierte una opción de diseño plausible en un supuesto hecho del sistema antiguo.

Use la conversación para una revisión adversaria. Pregunte qué se rompe si los registros llegan desordenados, si el trabajo se reinicia después de una escritura, si una cadena contiene un carácter no ASCII o si la llamada a la base confirma su transacción de manera independiente. Verifique luego las respuestas en el código o en pruebas de ejecución. El asistente resulta útil porque enumera rutas que una persona cansada puede saltarse, pero una pregunta inventada no demuestra que exista la ruta.

Evite conversaciones interminables que acumulen supuestos obsoletos. Cuando el conjunto de pruebas cambie de forma sustancial, inicie un análisis nuevo con los hechos corregidos y un registro breve de decisiones. De otro modo, una lectura errónea temprana puede permanecer en la conversación e influir en respuestas posteriores cuando el equipo cree que ya se corrigió. Guarde hallazgos duraderos en pruebas, notas de arquitectura o incidencias, no solo en el historial del chat.

Los agentes necesitan autoridad acotada y pruebas visibles

Un agente gana un alcance mayor cuando sus acciones pueden inspeccionarse y revertirse. Concédale los permisos mínimos que requiera la tarea, una rama o worktree aislado, instrucciones de configuración deterministas y comprobaciones de aceptación que fallen con claridad. Mantenga credenciales de producción y derechos de despliegue fuera del ciclo salvo que la tarea los exija y exista una puerta de aprobación humana.

Un informe de ejecución útil debe responder preguntas concretas:

• ¿Con qué estado del repositorio e instrucciones comenzó el agente?
• ¿Qué archivos leyó y cambió?
• ¿Qué comandos ejecutó y qué resultados de salida tuvieron?
• ¿Qué condiciones de aceptación pasaron o fallaron?
• ¿Qué incertidumbre queda y qué prueba la resolvería?

El diff sigue siendo necesario, pero no basta. Los revisores también necesitan el camino que lo produjo. Un agente puede borrar una prueba para que una suite pase, actualizar un snapshot que capturaba una regresión o elegir una configuración alternativa que nunca se ejecuta en producción. Los registros de comandos y los recuentos de pruebas anteriores y posteriores muestran algunos de estos atajos. La política del repositorio debe prohibir otros.

Contenga los fallos de forma mecánica. Limite las rutas escribibles cuando sea posible. Exija aprobación antes de comandos destructivos, cambios de dependencias, acceso a la red o modificaciones de la configuración de despliegue. Use límites de duración y número de archivos cambiados como alarmas, no como definiciones de corrección. Si salta una alarma, conserve el trabajo y las pruebas para revisarlos en vez de permitir que el agente amplíe su propia autoridad.

La seguridad y el cumplimiento necesitan un lenguaje preciso. Ejecutar un modelo dentro del perímetro del cliente puede satisfacer restricciones de ubicación de datos y red, pero no otorga una certificación a la herramienta ni al sistema resultante. Una instalación aislada de la red sigue necesitando controles de acceso, registros de auditoría, procedencia del modelo y dependencias, y un proceso que apruebe lo que sale del entorno.

Elija la herramienta por sus pruebas y radio de impacto

La elección debe seguir la afirmación que necesita hacer. Si es «esta línea sigue el patrón que ya entiendo», puede bastar el autocompletado. Si es «estos archivos implican este comportamiento», use un asistente y verifique las pruebas citadas. Si es «el repositorio ya cumple esta condición de aceptación», un agente puede reunir las pruebas si sus herramientas y permisos abarcan esa condición.

No compre el nombre de la categoría. Pida a los proveedores que demuestren el límite real de observación y acción. ¿Puede la herramienta leer todos los lenguajes del árbol? ¿Sigue enlaces generados y configurados? ¿Puede ejecutar la compilación y las pruebas de paridad en su entorno? ¿Muestra comandos y fallos? ¿Puede restringir escrituras, red y credenciales? ¿Qué hace exactamente que se detenga? Un parche pulido no responde ninguna de estas preguntas.

Para un sistema heredado, empiece la decisión con una tabla de riesgos, no con una lista de funciones. Coloque la ambigüedad del comportamiento en un eje y el radio de impacto en otro. Poca ambigüedad y poco impacto favorecen el autocompletado. Ambigüedad acotada con una decisión humana favorece el asistente. Mucha ambigüedad o un cambio entre sistemas exige un agente más un oráculo independiente, y a veces retrasar el cambio hasta que el equipo pueda capturar ese oráculo.

CodeHero utiliza el último modelo para reescrituras heredadas: su plataforma lee toda la base multilingüe, moderniza la arquitectura y compara el comportamiento con tráfico de producción registrado mediante un arnés de paridad. Entrega cada proyecto en menos de 30 días, pero el plazo no rebaja la exigencia de pruebas; el ciclo de acciones y el oráculo permiten discutir ese calendario en términos de ingeniería.

La adquisición debe utilizar una tarea que contenga al menos un patrón local engañoso, una dependencia entre lenguajes y un comportamiento visible solo en ejecución. Dé a cada candidato el mismo estado del repositorio y las mismas pruebas de aceptación. Compare afirmaciones sin respaldo, archivos excluidos, comandos, intentos fallidos y esfuerzo de revisión tan cuidadosamente como el parche final. Una herramienta que admite un enlace sin resolver es más segura que otra que llena el hueco con un supuesto fluido.

También importa la propiedad después de la ejecución. El equipo debe poder reproducir las comprobaciones, mantener el reemplazo y entender las excepciones restantes sin acceder a una sesión de chat desaparecida. Exija código ordinario, pruebas, instrucciones de ejecución y registros de decisiones. Si un proveedor no puede entregar la cadena de pruebas en formatos que sus ingenieros inspeccionen, el sistema sigue siendo desconocido después de reescribirlo, solo que en un lenguaje más nuevo.

Una herramienta nunca debe recibir más autoridad de la que justifican sus pruebas. En código desconocido, inspeccione qué vio, qué hizo y cómo intentó demostrar el resultado. Los tres nombres importan porque obligan a mantener esa conversación antes de que una sugerencia fluida se convierta en un cambio de producción sin examinar.