Lecciones para que Claude no repita un error

Ejemplo

Una consulta falla por un permiso vencido y el tablero muestra «0 ventas» en la región. Nadie lo cuestiona: un cero se ve como un dato.

Qué hacer

Si la lectura falla, muestra el error en la propia tarjeta, no un hueco ni un cero. Y un contador que dice «0 problemas» solo se cree si antes encontró un problema que le sembraste a propósito.

Ejemplo

«Fecha» puede ser la del evento, la de carga o la de partición. O «el jefe»: el que la persona tiene hoy, o el que tenía cuando pasó lo que estás midiendo.

Otro ejemplo

Una tabla de campañas traía la inversión de la empresa completa, pero los ingresos salían de una muestra de una compra de cada cien. Las dos columnas decían «pesos», y el retorno de todas las campañas salía negativo.

Qué hacer

Dale a cada variante un nombre distinto en el código y en la pantalla, aunque quede feo. Y antes de dividir o restar dos cifras de fuentes distintas, escribe de dónde sale cada una: si un resultado sale igual en todos los casos (todas pierden, todas ganan), sospecha de la escala antes que del negocio.

Ejemplo

La curva de ventas «cae» en el último punto, que es el mes que va a la mitad.

Qué hacer

Corta los indicadores al último periodo cerrado, o marca el periodo parcial en pantalla. Y separa los dos relojes: los números del grupo van a mes cerrado, las personas con nombre van al día.

Ejemplo

El sistema guarda solo el último jefe de cada persona. Para quien ya se fue, ese jefe quedó congelado, así que «la rotación del equipo de cada jefe» termina midiendo «este equipo ya no existe».

Qué hacer

Pregunta a la fuente si el dato es foto o historial antes de usarlo para mirar hacia atrás.

Ejemplo

Un modelo mejora de golpe muchísimo. Resulta que una variable vale 1 para todos los que se fueron y 0 para los que siguen, porque la fuente la llena distinto para cada grupo. Otra variante: el modelo aprende en qué año pasó algo, no a quién le pasó.

Qué hacer

Prueba hacia adelante: entrena con el pasado y evalúa en un periodo posterior. Y antes de normalizar por algo, pregunta si ese algo lo decide el resultado que quieres predecir.

Ejemplo

Un validador tenía escrito a mano que existían 43 elementos de referencia. Cuando el documento llegó a 47, rechazaba como inexistentes los cuatro nuevos. Ahora cuenta los del documento.

Qué hacer

Pon la definición en un punto que todas las consultas crucen, y haz que todas consuman de ahí. Un número escrito a mano que copia un dato de otro lugar también es una definición repetida.

No la confundas con

Repetir una explicación a propósito, en un material para aprender, no es copiar una definición. Lo que no se copia es la regla que calcula el dato.

Ejemplo

Una pantalla arma sus controles con la lista de variables que el modelo iba a usar. El entrenamiento descartó una, y durante días hubo un control que no movía nada.

Qué hacer

Deriva del resultado publicado. Y lo que no se pueda derivar, que falle en voz alta en lugar de desaparecer en silencio.

Ejemplo

Se actualizaron las etiquetas de tres pantallas tras cambiar un modelo. La cuarta, que nadie recordaba, siguió ofreciendo opciones del modelo anterior.

Otro ejemplo

Al escribir un capítulo se afirmó de memoria que el lector ya conocía tres funciones de un capítulo anterior. Una búsqueda mostró que ese capítulo enseñaba solo una, y que otro ya había explicado el tema que se presentaba como nuevo.

Un ejemplo más

Un cambio se guardó con la lista de archivos escrita de memoria, y quedó fuera uno: el que hacía funcionar lo nuevo. Lo mostró la lista de cambios pendientes, revisada después.

Qué hacer

Mantén un mapa escrito de impactos por tipo de cambio. Recórrelo completo diciendo «cambia» o «no aplica porque…», y si el cambio crea un consumidor nuevo, agrégalo en el mismo cambio. Antes de citar, copia de la fuente citada la frase que afirmas: lo que se dice que otro hizo o vio también se comprueba.

Ejemplo

Un pendiente se marcó como cerrado en la lista, pero la prueba que lo vigilaba seguía marcada como «se espera que falle» y el documento lo describía como abierto. Tres lugares, tres versiones.

Qué hacer

La unidad de trabajo es el conjunto completo, en el mismo cambio.

Ejemplo

La versión de escritorio ganó un filtro por fecha. La de celular, que la gente ve como «la misma pantalla», siguió sin él durante un mes.

Qué hacer

No cierres el cambio hasta revisar el gemelo y decir «igual» o «no aplica porque…».

Ejemplo

Se retira una gráfica poco confiable, pero una tarjeta de «hallazgos clave» y un plan de acción seguían recomendando lo que la gráfica decía.

Otro ejemplo

Un plan de capítulos se renumeró de 7 a 15. Dos listas de otro documento siguieron apuntando al «7.4» y al «7.7» del plan viejo, que ahora eran otros temas. Al reemplazar un plan, los números viejos también son afirmaciones.

Qué hacer

Busca por tema, no por identificador. Los ecos no tienen nombre de variable.

Ejemplo

Una pregunta de opción múltiple afirmaba que comparar un número con un texto entre comillas da error. En otros motores sí; en el que de verdad usaba la gente, la consulta corría y devolvía filas.

Otro ejemplo

Un texto explicaba bien que un bloque con nombre vive solo dentro de su consulta, pero su propio ejemplo daba por hecho que tres consultas separadas lo compartían. Corrida, la segunda consulta daba error: la tabla no existía.

Un ejemplo más

Se corrieron todos los ejemplos de una página, y aun así tres frases salieron falsas: la explicación de una opción, escrita al final, decía qué hace una línea que nadie corrió; una regla para leer errores («si dice esto, falta aquello») la contradecía otro paso de la misma página; y la introducción decía que una función «da un resultado» cuando no lo hace.

Qué hacer

Reconcilia contra una cifra conocida, el sistema de origen o el periodo anterior. Prueba en el entorno real: con sus permisos, sus librerías y la copia del código que de verdad se ejecuta. Cada afirmación sobre cómo se comporta el sistema se corre una vez antes de escribirla, también la que aparece de paso en un ejemplo o se escribe de último. Si la afirmación es una regla general («solo», «siempre», «nunca»), busca el caso que la rompería y córrelo también: «la conversión a entero solo lee enteros» se comprobó con un texto con decimales, y resultó falsa con un número con decimales. Al decir una fracción («cinco de cada seis»), nombra el todo del que sale; y un escenario inventado también se mide: el tamaño, la diferencia y el valor p tienen que cuadrar entre sí.

Ejemplo

Una prueba que prohíbe una palabra solo buscaba la versión en minúsculas; con mayúsculas o con un acento pasaba.

Otro ejemplo

Se sembraron 37 registros duplicados para un ejercicio y el conteo dio 92: los datos ya traían coincidencias naturales. Lo atrapó una comprobación que, antes de guardar, comparaba el conteo con lo sembrado.

Un ejemplo más

Una regla que detectaba código sangrado marcó una línea que empezaba con un texto: el caso que debía pasar no traía esa forma. Y una prueba de que el texto se comparaba bien pasaba aunque la comparación estuviera rota, porque otra revisión rechazaba antes el error.

Qué hacer

Calibra con dos casos: uno donde debe encontrar y otro donde no debe, y córrela de verdad el día que nace. El caso bueno importa tanto como el malo: un verificador que rechaza lo correcto también está roto, y se nota menos, porque parece exigente. El caso bueno lleva las formas reales de lo correcto, también las que no escribiste tú: otro orden, otro nombre. Cada verificación se calibra sola: si otra atrapa el error antes, la tuya nunca se probó. Y una revisión que repite lo que ya leyó no puede fallar (una «segunda corrida» que vuelve a leer el mismo archivo): cámbiala por un cuadre que sí falle si algo está mal.

Ejemplo

Se buscaba un problema de acentos mandando consultas con acentos por la misma vía que los dañaba.

Qué hacer

Construye la prueba en una forma que el daño no pueda tocar.

Ejemplo

Una prueba ubicaba una tabla por su título y, si no lo encontraba, se saltaba. El título cambió, y la prueba pasó durante semanas sin mirar nada.

Variante

Una verificación que se cae con el primer archivo roto deja sin vigilar todos los que venían después. Un validador que truena, en lugar de reportar «esta página no se puede leer, línea 12», apaga la revisión entera.

Qué hacer

Si lo que falta es una herramienta, saltarla es honesto. Si lo que falta es el dato vigilado, la prueba debe fallar. Y un archivo que no se puede leer es un hallazgo con su línea, no el fin de la revisión.

Ejemplo

Un auditor de diseño revisaba solo los elementos sin hijos. Los rótulos que había que revisar tenían dentro un ícono de ayuda, así que nunca los vio.

Otro ejemplo

Una prueba recorría cada página marcando siempre la primera opción y corriendo cada consulta tal como venía. Pasaba siempre, y nunca comprobó que la respuesta correcta se aceptara.

Un ejemplo más

Para decidir si alguien cambió un texto, se ignoraron los espacios. Eso dejó fuera justo el caso de la página que explicaba cómo acomodar ese texto con espacios y saltos de línea. Normalizar también es filtrar.

Qué hacer

Escribe qué deja fuera el filtro y revisa a mano una muestra de lo excluido. Y cuando aprendas que un filtro te dejó ciego, busca los otros filtros parecidos que ya escribiste: una revisión que quitaba todos los espacios del código pegó dos palabras en una, y rechazó código correcto, poco después de que se aprendiera la misma lección con otra normalización.

Ejemplo

Una página pasaba la revisión de sintaxis y la de tipos. Al abrirla quedaba en blanco: usaba una variable que solo existe en el servidor.

Qué hacer

Ten al menos una prueba que ejecute la página o el programa completo.

Ejemplo

Se verificaba que cada resultado publicado fuera correcto, pero a la pantalla viajaba una versión armada a partir de él, que usaba otra regla para los datos faltantes.

Otro ejemplo

Un revisor leía el archivo fuente de cada página y lo aprobaba. Una tabla que en el celular se apilaba en tarjetas, y ya no se podía comparar, solo apareció al mirar la página.

Qué hacer

Comprueba en el punto donde llega a la persona: la página como se ve, el archivo que descarga, el mensaje que recibe (ver también la 41).

Ejemplo

Se homologó el diseño de dos pantallas en cuatro rondas: primero el tamaño, luego la tipografía, luego los colores, luego el color de los rótulos. Cada entrega decía «ya quedó».

Otro ejemplo

Las ilustraciones de un material se revisaban por contenido y por tamaño, pero no por contraste: dos colores de texto quedaron por debajo del mínimo legible en cuatro imágenes.

Qué hacer

Enumera todas las diferencias antes de corregir la primera. Y en tus registros, el verbo te delata: «queda», «pasa a» son intención; «dice», «muestra» son medición.

Ejemplo

Una leyenda con los rangos de una clasificación se insertó una vez. Cambiaron los rangos y la leyenda siguió mostrando los viejos.

Qué hacer

Reemplaza: quita lo anterior, vuelve a inyectar y comprueba que quedó una sola copia.

Ejemplo

Se agregó un ícono de ayuda junto a varios títulos, y las actualizaciones que se ubicaban por esos títulos dejaron de funcionar.

Otro ejemplo

Una revisión buscaba el texto «int(» para saber si alguien convirtió un número, y lo encontraba dentro de «print(»: cualquier línea que mostrara algo parecía cumplir. Lo buscado tiene que ser una palabra completa, no un pedazo de otra.

Un ejemplo más

Una revisión tomaba la última línea que mostraba el código como su respuesta. Con una función que muestra el número por dentro y no lo devuelve, esa línea existía por otra razón: la respuesta se veía, aunque el código no la entregaba.

Qué hacer

Usa marcadores propios, como un identificador o un comentario de sección. Y cuando un cambio toca muchos bloques a la vez, revísalos todos, no solo el primero.

Ejemplo

Para comprobar que un script no cambiaba nada en su segunda corrida, se comparó dos veces la huella de la misma corrida, y después dos huellas sacadas de listas de archivos distintas. Las dos comparaciones decían «igual» o «distinto» sin probar nada. La comparación que sirve toma la huella, corre el script y toma la huella otra vez, de los mismos archivos y en un solo comando.

Qué hacer

Córrelo dos veces desde el mismo punto de partida y compara los archivos: la segunda corrida no debe cambiar nada.

Ejemplo

Un script insertaba una celda de título antes de la celda 9 de un cuaderno y después editaba «la celda 9»: editó la que acababa de insertar.

Qué hacer

Vuelve a ubicar el lugar después de cada inserción, y comprueba el resultado revisando la estructura completa.

Ejemplo

Un script abría el archivo de configuración para reescribirlo, fallaba al calcular uno de los valores y dejaba el archivo vacío. El servidor no volvió a arrancar.

Qué hacer

Prepara todo en memoria, escribe a un archivo temporal y al final reemplaza el original de un solo golpe.

Ejemplo

Una tarea programada aparecía «activa» y llevaba dos meses sin correr por una credencial vencida. El tablero mostraba el último dato como si fuera de hoy.

Qué hacer

Muestra en pantalla cuándo se actualizó el dato por última vez. Comprueba qué periodos faltan. Y haz que los procesos se puedan repetir sin duplicar filas.

Ejemplo

Un reporte publicado hacía un año seguía filtrando por una columna que la fuente había dejado de llenar. Mostraba cero, y como «ya estaba validado», nadie volvió a preguntar.

Qué hacer

Somete a lo que ya está en uso a las mismas pruebas que al candidato nuevo, en cada revisión.

Ejemplo

Una tabla «perdió la mitad de sus columnas». Minutos después estaba completa: la estabas viendo mientras otro proceso la reconstruía.

Otro ejemplo

Una imagen nueva «no cargaba» en la página. El archivo estaba bien: el servidor de prueba no veía las carpetas creadas después de arrancar.

Un ejemplo más

Un script «calculaba mal» un patrón de texto. El script estaba bien: la consola por la que se pasó convirtió cada \n en un salto de línea real antes de que el script lo leyera. Y en un cuaderno donde las celdas comparten memoria, un error que se quería mostrar no salía: la variable seguía guardada de una celda anterior.

Qué hacer

Toma una segunda foto con minutos de diferencia antes de declarar una catástrofe. Si un instrumento ya te falló de la misma forma, cámbialo en lugar de vigilarlo: un tropiezo repetido no es mala suerte, es la herramienta equivocada. Una consola que transforma \n o \\ en el camino no sirve para pasarle código: el código va en un archivo, escrito con una herramienta que no lo toque, y se corre desde ahí. Y lo que es mecánico (un comando que ya falló tres veces) se bloquea con un guardia, no se recuerda.

Ejemplo

Quien escribía cada página tomaba también las capturas de revisión, y solo de los pasos que creía riesgosos. El revisor leía el archivo fuente. Los pasos sin captura no los vio nadie.

Qué hacer

Uno ejecuta y el otro comprueba leyendo el resultado. «Ya lo hice» es el aviso de que ya se puede verificar, no la verificación. Y el que verifica no mira por el mismo canal que quien hizo (ver la 14): si los dos leen solo la fuente, ninguno ve la pantalla.

Ejemplo

Un comando de despliegue traía el nombre de una rama escrito de memoria. La rama se llamaba distinto, y quien lo corrió perdió media hora antes de preguntar.

Qué hacer

Córrelo tú antes de pasarlo, y copia cada nombre (script, ruta, rama) del sistema, no de la memoria.

Ejemplo

Se reorganizó la estructura de carpetas de un proyecto entero sin avisar. El cambio era correcto en sí mismo y se deshizo completo, porque otra persona ya había decidido esa estructura por razones que no estaban en el código.

Qué hacer

Antes de cada bloque de trabajo grande, explica en lenguaje sencillo qué harás y por qué, y espera la confirmación.

Ejemplo

Una pantalla de ventas mostraba en la primera fila el identificador interno de cada pedido y la hora del último cálculo. Nadie decidía nada con eso, y ocupaba el lugar del dato que sí importaba.

Qué hacer

Antes de agregar algo a la pantalla, escribe qué decisión cambia. Si no cambia ninguna, va al registro técnico o al código, no a la pantalla.

Ejemplo

Un filtro sí filtraba una tabla, pero la tabla estaba dos pantallas más abajo. Lo reportaron como «no hace nada».

Variante

Ocultar un contenedor oculta todo lo que vive dentro, incluso lo que no tenía que ver con él. Por ejemplo, un enlace útil que vivía dentro de un control retirado.

Qué hacer

Todo control dice qué cambió y lleva al usuario hasta ahí. Y antes de ocultar algo, revisa qué otros elementos viven dentro.

Ejemplo

Dos personas distintas leyeron «98 ÷ 441» como «98 + 441» en una tarjeta con letra pequeña, y las dos reportaron que la cuenta estaba mal.

Otro ejemplo

La fuente de código de un material unía >= en un solo símbolo, ⩾. Quien aprende copia lo que ve, y ese símbolo no existe en el teclado ni en el lenguaje.

Qué hacer

Cuando un símbolo se confunde, cámbialo por una palabra: «98 sobre 441» en lugar de «98 ÷ 441».

Ejemplo

Un reporte pidió arreglar una gráfica que sumaba mal, pero esa gráfica no existía en la pantalla: el dato viajaba sin que nada lo dibujara.

Qué hacer

Mide antes y después del arreglo. Un arreglo que mejora el síntoma a medias todavía no está cerrado.

Ejemplo

Una nota decía «quitar el filtro de fechas». Cuando por fin se trabajó, el filtro ya era una decisión escrita del equipo, y quitarlo rompió un reporte.

Qué hacer

Antes de trabajar un pendiente, mídelo hoy y busca si alguna decisión escrita dice que se quedó así a propósito.

Ejemplo

Una explicación decía que un error hacía perder «casi uno de cada cinco» boletos. Al medirlo eran más de uno de cada cinco: la frase venía del cálculo mental, no del dato.

Otro ejemplo

Un texto decía que un grupo de cohortes «andaba arriba del 50 %»; cinco de las doce quedaban abajo. En otro, la ilustración traía una cuenta hecha a mano que no cuadraba: el porcentaje por el total no daba el resultado dibujado.

Qué hacer

Antes de escribir una cifra, mídela otra vez y anota junto a ella de qué dato y de qué fecha salió. Las palabras de cantidad («casi», «más de», «la mayoría») son cifras con disfraz: se miden igual. Y si una imagen trae cuentas, que las haga el mismo script que la dibuja.

Ejemplo

Un manual decía que los datos se sincronizaban solos. El sistema solo sincronizaba al abrir la aplicación. La revisión «corrigió» el manual para prometer que pronto sería automático, en lugar de declarar el límite tal cual.

Qué hacer

Separa los hallazgos del documento («está mal escrito») de los del sistema («funciona distinto de lo ideal»). Los segundos se declaran como limitación.

Ejemplo

Un procedimiento traía un tiempo de respuesta de 24 horas que nadie había acordado: se escribió porque sonaba razonable, y al publicarse se volvió compromiso.

Qué hacer

Marca lo que falta de forma visible, como «Pendiente» en rojo, y pregunta a quien sí lo sabe. Una redacción neutra es mejor que una falsa.

No la confundas con

La marca es para quien decide, no para el lector final: un «pendiente de confirmar» dentro de un texto publicado es otro dato que no debía estar ahí. Si el documento sale antes de confirmarlo, usa una redacción neutra que no afirme lo que falta, y deja el pendiente en el informe o el registro del proyecto.

Ejemplo

Dos copias de un manual circulaban por correo. La vieja decía que la herramienta «se abre con doble clic», algo que ya no era cierto, y nadie podía saber cuál de las dos era la buena.

Qué hacer

Sube el número de versión y escribe la línea del historial en el mismo cambio que modifica el documento.

Ejemplo

Un historial decía «se intentó A y falló; se intentó B y falló; quedó C». Quien lo leía meses después solo necesitaba C y su razón, y tuvo que leer tres párrafos para encontrarla.

Qué hacer

Escribe el estado final y su razón. Lo que se intentó y falló solo entra si enseña algo que alguien necesita para no repetirlo.

Ejemplo

Tres pasos numerados salían como viñetas vacías. La revisión automática los daba por buenos porque esas palabras aparecían en otra parte del documento.

Otro ejemplo

Se agregó un aviso de «hay más columnas a la derecha» y se dio por hecho porque el código estaba ahí. Nunca aparecía: un estilo general de las tablas le quitaba la condición que lo encendía. Lo vio otra persona en una captura.

Un ejemplo más

Una opción de respuesta decía en el archivo «Total: {2 * 78}». Al dibujar la página, el sistema calculó lo que iba entre llaves y mostró «Total: 156»: dos opciones idénticas. Solo lo vio quien miró la pantalla.

Variante

Las capturas que juzga un revisor pueden mostrar una pantalla a la que nadie llega. La herramienta de capturas de un curso contestaba cada ejercicio de código con una línea de relleno solo para avanzar, así que la captura de «después» mostraba esa línea y el aviso «no es el resultado esperado»: los revisores nunca vieron lo que ve un estudiante que acierta. En escritorio, además, las capturas incluían la cabecera y el menú lateral, y la lección quedaba como una franja ilegible. Al capturar para revisar, contesta cada paso como lo haría quien acierta, y captura solo la parte que se revisa.

Qué hacer

Verifica el elemento exacto, como «estos tres pasos, como viñetas», y mira al menos una vez la página tal como la verá el lector. Un arreglo chico se mira igual: es donde menos se espera que otra regla lo anule. Y la primera vez que usas un recurso nuevo en la página (un bloque de código, un encabezado fijo), míralo también en el celular.

Ejemplo

Una reorganización del manual se hizo sobre una versión de semanas atrás y volvió a decir que la herramienta «se abre con doble clic», algo que ya no era cierto.

Qué hacer

Aprovecha la estructura que propone la revisión y vacía en ella el contenido más reciente, no al revés.

Ejemplo

Un apartado decía que sin conexión no se guarda nada, y las preguntas frecuentes seguían diciendo que lo capturado se conserva en el equipo.

Qué hacer

Al cerrar cada ronda, busca por tema todo lo que dice el documento sobre lo que corregiste.

Ejemplo

Una página se marcó como revisada porque su prueba «terminó sin errores». El resultado pasaba por un comando que mostraba solo el final, y el aviso de que la prueba había fallado se perdió en el camino.

Otro ejemplo

Una suite de pruebas reintentaba sola cada prueba que fallaba. Las que pasaban al segundo intento no contaban como falla, solo como «inestables», y la causa quedó escondida: cada cambio de paso volvía a pedir la página al servidor. Sin reintentos, la falla apareció y se pudo medir.

Qué hacer

Busca la línea del veredicto antes de cambiar un estado. Si encadenas comandos, haz que el fallo del primero llegue hasta el final. Si la salida no trae veredicto, eso es un «no sé», no un «pasó» (ver la 1). Y guarda la salida completa en un archivo y busca ahí el veredicto: así no tienes que decidir antes cuánto leer.

Ejemplo

Una celda de consulta contaba un intento solo cuando la consulta corría. Con un error de escritura, el botón para avanzar nunca se activaba y la persona se quedaba atorada. Las pruebas pasaban, porque siempre corrían la consulta de partida, que no tenía errores.

Qué hacer

Por cada control, prueba tres caminos: el bueno, el del error más común y el vacío. Los tres dicen qué pasó y dejan seguir.

Ejemplo

Cada página de un sitio leía y analizaba todo el contenido para armar el temario. Sola, una página tardaba 0.4 s. Pero la barra lateral pedía unas 40 a la vez, y juntas tardaban 16 s. Meses después, las pruebas empezaron a fallar al cambiar de página, y la falla parecía de la prueba.

Qué hacer

Mide en el servidor compilado y como lo usa la gente, con todas sus peticiones juntas, no una página sola. Guarda lo que no cambia mientras corre el servidor, y deja una prueba que lo mida con el caso que de verdad lo hacía lento.

Ejemplo

Cuatro personas escribían a la vez una pieza cada una y dejaban lo compartido como entrega. Al integrar, dos entregas usaban un nombre que ya existía en la prueba común, y la prueba dejó de correr. Otra prueba guardaba una copia de lo que revisaba, la pieza cambió y la copia no. Una corrida de las pruebas falló por una imagen que otra persona todavía estaba dibujando. Y al final no se podía guardar cada pieza por separado: los archivos comunes ya traían cambios de todas.

Qué hacer

Que lo compartido lo integre una sola persona, con un paso que se detenga si un nombre choca. Que las pruebas lean el original, no una copia. Corre las pruebas completas cuando todas terminen, o sin las piezas que siguen cambiando, y di cuáles quedaron fuera. Y guarda juntas las piezas que comparten archivos, para que cada versión guardada funcione completa.

Ejemplo

Una nota se armaba con las secciones que entregaba cada persona. Tres filas se corrigieron directo en la nota, y al volver a armarla desde las entregas regresaron las tres filas viejas. En otra pieza, un revisor corrigió a mano el texto alternativo de una página que salía de una plantilla; quien la escribió volvió a generarla y el arreglo desapareció.

Qué hacer

Antes de corregir un archivo, averigua de dónde sale. Corrige la fuente (la plantilla, el script, la entrega) y vuelve a generar; si tienes que corregir la salida, corrige también la fuente en el mismo paso. Quien revisa algo generado avisa qué cambió para que pase a la fuente. Y antes de rehacer un archivo desde sus fuentes, compáralo con lo que va a salir: lo que difiera es un arreglo que se perdería.

Ejemplo

El estilo del foco del teclado, escrito para todo el sitio, traía su propio redondeo. Como quedaba por encima de los estilos de cada componente, un botón en forma de píldora cambiaba de forma al enfocarlo con el teclado. Nadie lo vio, porque con el ratón el foco no aparece.

Qué hacer

Que la regla general toque solo lo suyo (el contorno del foco, no la forma). Si debe ganar a propósito, escríbelo junto a ella. Y pruébala en la pieza más distinta, no solo en la común.

Ejemplo

Una lección comparaba subir cinco puntos la primera etapa de un embudo contra subirlos en la última. Ganaba la primera, y el texto decía: «valen más donde hay más visitas». Pero la primera etapa también era la que menos convertía, y esa era la causa: en un embudo donde la primera convierte mejor, gana la última aunque tenga menos visitas. En otro proyecto se culpó a una página de tardar 2.7 s; una prueba que pedía las páginas una por una pasaba aun sin el arreglo, porque la causa real eran cuarenta peticiones al mismo tiempo.

Qué hacer

Antes de enseñar o reportar por qué pasa algo, escribe la explicación rival y arma un caso donde las dos predigan distinto. Compara partes del mismo tamaño, prueba con otro tamaño de ejemplo y mide una afirmación general en datos simulados antes de escribirla. Si no logras separarlas, di que el ejemplo es compatible con las dos.

Ejemplo

Un curso de programación para principiantes empezaba con una celda que traía seis cosas nuevas a la vez, y el plan nunca enseñaba qué es un tipo de dato ni que el = guarda y se lee de derecha a izquierda. La dueña del curso lo dijo en una frase: «asumes muchas cosas de los estudiantes». Después, tres lecciones decían «como arrastrar una fórmula», y ninguna lo había enseñado: decían «copiar la fórmula hacia abajo».

Qué hacer

Antes de escribir, lista lo que tu ejemplo da por sabido (símbolos, palabras, clics, cosas que el estudiante ya debería haber armado) y enséñalo primero: una idea nueva a la vez, cada símbolo explicado la primera vez que aparece. Busca cada palabra que coincide con el nombre de un botón, y cada acción que pides, como buscas un símbolo. Si se puede, deja que una revisión automática compare lo que usa cada ejemplo con lo que ya se enseñó.

Ejemplo

El plan de un módulo de «análisis con IA» empezaba con «la IA no ve tus datos, así que describe tu tabla en lugar de pegarla». La dueña del curso señaló que hoy los agentes se conectan a la base, corren las consultas solos y devuelven el número. Una investigación con fuentes y fechas lo confirmó: copiar código de un chat era como se trabajaba dos años antes. Varias lecciones se reescribieron alrededor de lo que sigue siendo cierto: definir la pregunta, supervisar al agente y comprobar el número.

Qué hacer

Antes de escribir sobre una herramienta que cambia rápido, investiga la práctica actual con fuentes y fechas: qué hace hoy, qué es gratis, qué usa de verdad la gente. Arma el texto alrededor de la habilidad que sobrevive a la siguiente versión (plantear, supervisar, verificar) y deja los pasos de la herramienta en un solo lugar que se pueda actualizar. Marca lo que no pudiste comprobar y pruébalo a mano antes de publicar.

Ejemplo

Dos ediciones en una misma sesión, las dos en Windows PowerShell 5.1. Una lectura, reemplazo y escritura de un script (Get-Content, -replace, Set-Content -Encoding utf8) leyó el archivo en la página de códigos ANSI del sistema y lo escribió de vuelta como UTF-8: cada ✓ y · del archivo se volvió ✓ y ·, y su autoverificación imprimió la marca dañada. Luego, una lista de reemplazos escrita como `@('old', 'new' + "n" + 'more')` perdió líneas: en PowerShell la coma liga más fuerte que +`, así que cada par se volvió cuatro elementos y solo se escribió el primer pedazo del texto nuevo.

Qué hacer

Cambia el código con las herramientas de editar y escribir del propio editor. Cuando el cambio tenga que hacerse con un script, escribe el script en un archivo y córrelo con un intérprete que lea y escriba UTF-8 y tenga literales de cadena simples (node fix.mjs, python -I fix.py). Luego revisa el diff: un cambio que tocó más líneas de las que querías, o caracteres que no tocaste, es culpa de la consola.

Ejemplo

Una práctica pedía la compra más grande del verano, con un filtro de fechas. La más grande de toda la tabla también era del verano: sin el filtro salía el mismo número, y el ejercicio la aceptaba. Otra exigía que el código tuviera un =, y pasaba con el resultado tecleado a mano, total = 1945. La revisión miraba la letra, no la habilidad.

Qué hacer

Resuelve cada ejercicio tres veces: sin tocarlo, con el error más probable y bien. Solo la tercera debe pasar. Prueba en todos la misma lista de atajos: el número tecleado, el código de partida con la respuesta agregada al final, el síntoma corregido a mano en lugar de la causa, la palabra exigida usada vacía, y una corrida con la memoria de un intento anterior. Deja la tolerancia más chica que la distancia entre la respuesta y el error probable, y escribe tres formas correctas que usaría un estudiante, para no rechazar lo que está bien.

Ejemplo

Una ilustración con la cifra correcta quedaba arriba de la práctica que pedía calcularla. Una lección preguntaba qué pasa al guardar otro valor en una variable, en un paso titulado «Guardar otra vez reemplaza». Un resumen debajo del quiz final se leía antes de contestarlo. Y un recuadro que aparece tras el primer intento, aunque falle, daba la dirección de la respuesta.

Qué hacer

Busca cada respuesta en todo lo que se ve antes de su pregunta, también en lo que aparece tras un primer intento fallido, en lo que imprime el código de partida al correrlo, en los archivos que se descargan y en lo que se puede contar en un dibujo. Escribe el título del paso y los objetivos al final, y léelos junto al resultado de cada predicción. Una revisión automática encuentra las cifras exactas; las aproximaciones y las frases con otras palabras solo las encuentra quien lee con la respuesta en mente.

Ejemplo

Una pregunta pedía qué hacer con un descuento vacío «cuando la venta no tuvo descuento». La lección había enseñado que un vacío que es un dato se deja, así que «dejarlo» se defendía; la respuesta esperada, rellenar con cero, dependía de algo que el enunciado no decía: que se quería el promedio de todas las ventas. En otra, «la medida principal es la parte que paga el segundo mes» no decía de quiénes, y las dos versiones empataban o no según cómo se leyera.

Qué hacer

Para cada opción equivocada, escribe en una línea por qué está mal usando solo el enunciado y la lección. Si para descartarla necesitas un dato que no está escrito, agrégalo al enunciado: el propósito de la cuenta, la regla del sistema, el denominador de una proporción, lo que se sabe de los datos. En un ejercicio de clasificar, prueba cada elemento contra cada categoría, no solo contra la suya.

Ejemplo

En el quiz de cierre de un módulo, la correcta era la segunda opción en seis de siete preguntas. En todo un curso, la correcta era la más larga en el 55 % de las preguntas, cuando al azar, con tres opciones, toca una de cada tres. Después de emparejar los largos a mano, la correcta quedó como la más corta en seis de siete preguntas de una lección, y en medio en todas las de tres lecciones seguidas.

Qué hacer

Baraja las opciones al mostrarlas, con un orden que no salga de dónde se escribió la correcta. Mide la más larga, la más corta y la de en medio por archivo, y junta por módulo los archivos chicos, para que unas pocas preguntas no escondan el patrón. Lee el conteo contra lo que pediste: emparejar a mano puede mover la pista en lugar de quitarla.

Ejemplo

Al revisar las 277 prácticas revisadas de un curso, cambiaron 82 pistas en 49 archivos. Unas daban la línea que resuelve («el segundo es la…»). Otras dictaban el orden que separa la solución de su error común. En los ejercicios de cuadrar contra un resultado anterior, la pista decía «debe dar lo mismo que en la lección 2.2»: quien recordaba el número de antes lo podía escribir sin hacer el paso.

Qué hacer

Escribe la pista sobre la causa del error probable («las posiciones empiezan en 0, no en 1») y cita solo lo ya enseñado. Deja el «debe dar lo mismo que antes» para la explicación que aparece al responder, donde enseña que dos métodos con el mismo número son una verificación. Revisa cada pista contra el error más probable de su ejercicio, no sola.

Ejemplo

En las dos corridas de la primera simulación Web, el formulario guardaba cada mensaje como una línea JSON, y el panel de administración omitía las que no podía leer. Con una línea cortada al final del archivo, el mensaje siguiente recibió la respuesta «¡Gracias!», se guardó y nunca apareció en el panel de administración. Una de las dos versiones tenía un comentario que decía «línea dañada: se omite».

Otro ejemplo

En las dos corridas de la repetición, todos los mensajes vivían en un solo archivo JSON que se escribía en un archivo temporal y luego se renombraba, así que un fallo a media escritura ya no hacía daño. Pero con el archivo dañado de cualquier otra forma (una edición a mano, un disco lleno, una restauración mal hecha), cada visitante nuevo recibía «Error interno», la página de administración no mostraba nada, y la única señal era un error en la consola del servidor.

Qué hacer

Haz que un registro nuevo no dependa de los anteriores: agrégalo al final de un archivo que termine en salto de línea (si no termina, empieza el registro con uno), o guarda cada registro en su propio archivo, en lugar de reescribir un archivo que los contiene todos. Al leer, cuenta lo que no se pudo leer y muestra ese número donde lo vea el dueño. Pruébalo dañando el almacenamiento a mano (corta la última línea, trunca el archivo) y después envía un registro.

Ejemplo

En las dos corridas de la simulación Web, el formulario de contacto aceptó 650 mensajes de un script en un par de segundos, todos con «gracias». La administración no tenía páginas ni botón de borrar: pasó a medir entre uno y seis millones de píxeles de alto, y en el celular el texto del mensaje quedaba fuera de la pantalla. Las dos veces el constructor lo dejó anotado como pendiente.

Qué hacer

Desde el inicio, un freno barato: un campo oculto que las personas no llenan y un límite de envíos por dirección por minuto. Y una administración con páginas, lo más nuevo primero, y una forma de borrar o marcar como basura. Pruébalo mandando cientos de mensajes con un script y abriendo la administración en el celular.

Ejemplo

En las dos corridas de la simulación Web, el formulario enviaba con JavaScript y declaraba method="post". Sin JavaScript, en una versión el servidor rechazaba el envío con una línea de JSON y el mensaje se perdía; en la otra lo guardaba y mostraba solo {"ok":true} en una página en blanco. Esta segunda versión decía en su resumen que sin JavaScript no enviaba.

Qué hacer

Decide una de dos y pruébala: o el servidor acepta el envío normal y responde con una página (o redirige a una de gracias), o el formulario no declara un respaldo que no tiene. Envíalo una vez con el JavaScript apagado.

Ejemplo

En las dos corridas de la simulación Web, el envío deshabilitaba el botón. Con un correo que el servidor rechazó, el aviso apareció debajo del botón, el foco quedó en el documento y el siguiente Tab llevó al primer enlace de la página, lejos del campo que había que corregir.

Qué hacer

Al terminar el envío, pon el foco donde sigue la persona: en el campo con error (marcado con aria-invalid y su mensaje junto a él) o en el aviso de éxito. O evita el doble envío sin deshabilitar, con aria-disabled y una bandera. Recorre el error solo con teclado.

Ejemplo

En las dos corridas de la repetición de la simulación Web, la página de administración pedía contraseña y nunca limitaba los intentos fallidos: 200 contraseñas incorrectas seguidas recibieron 200 rechazos en menos de un segundo, y ninguna fue bloqueada. La contraseña predeterminada era larga y aleatoria, pero el resumen final de quien construyó el sitio le explicaba al dueño cómo poner una nueva, y nada exigía que fuera larga.

Qué hacer

Frena o bloquea los fallos repetidos, por dirección y por cuenta, con una espera que crezca con cada intento. Exige una longitud mínima cuando el dueño ponga una contraseña. Pruébalo: envía veinte contraseñas incorrectas seguidas y comprueba que las últimas se rechazan.