- Incluso en un entorno donde la IA genera código, diseños y respuestas, el pensamiento crítico para hacer las preguntas correctas y cuestionar supuestos es una capacidad clave que determina el rendimiento de los ingenieros y de los equipos
- A lo largo de todo el proceso de resolución de problemas, hay que usar sistemáticamente las seis preguntas Who·What·Where·When·Why·How para revisar personas, problema, contexto, momento, causa y forma de ejecución
- Las respuestas de la IA deben tratarse como un borrador propuesto por un interno y sujeto a verificación, y se necesita una estructura donde la definición real del problema, la recolección de evidencia, la comprensión del contexto, el análisis de causas y la comunicación sigan siendo responsabilidad humana
- Por la presión de tiempo, los sesgos y las respuestas convincentes de la IA, es fácil caer en conclusiones apresuradas y soluciones parche, por lo que hay que repetir un pensamiento basado en evidencia con herramientas como 5 Whys, experimentos y validación de datos
- El pensamiento crítico se fortalece en una cultura de equipo que valora la curiosidad humilde y la evidencia, y por más que la IA avance, “resolver el problema correcto, por la razón correcta y de la manera correcta” sigue siendo una ventaja propiamente humana
Panorama general del pensamiento crítico en la era de la IA
- En una era en la que la IA genera código, diseño y respuestas, la capacidad humana de pensar críticamente se vuelve más importante que antes
- Por más sofisticada que se vuelva la automatización, hacer las preguntas correctas, cuestionar supuestos y pensar de forma independiente sigue siendo tarea de las personas
- Los resultados de IA construidos sobre preguntas equivocadas y problemas mal definidos pueden empujar un proyecto más rápido en la dirección incorrecta
- Se propone una guía práctica concreta usando el marco Who·What·Where·When·Why·How para el pensamiento crítico
- Cada pregunta sirve como herramienta para revisar la definición del problema, las partes interesadas, el contexto, el momento, el análisis de causas y la forma de ejecución y comunicación
- No perder de vista estas seis dimensiones en un entorno asistido por IA es clave para reducir fallas de proyecto y prevenir problemas downstream
tl;dr: checklist de pensamiento crítico para equipos de IA
- Who: Considerar a la IA no como una entidad omnisciente, sino como una entrada que necesita verificación, y confirmar siempre quién está produciendo la respuesta
- Hace falta una perspectiva que no equipare la respuesta de un LLM con la opinión de una persona, y que separe la fuente de la responsabilidad
- What: Antes de correr hacia la solución, hay que dejar clara la definición del problema real y los criterios de éxito
- Más allá de requisitos superficiales, hay que definir con precisión el problema real a resolver a partir de la experiencia del usuario y los datos
- Where: Hay que considerar el contexto y el entorno donde se aplicará la solución (sandbox, producción, dispositivo del usuario, etc.)
- Siempre hay que tener presente que una solución que funciona bien en un entorno puede generar efectos secundarios en otro
- When: Hay que distinguir entre situaciones donde basta una heurística simple y situaciones que requieren un análisis profundo
- Separar el momento del parche de emergencia del análisis de causa raíz permite mantener un mínimo de rigor incluso bajo restricciones de tiempo
- Why / How: Hay que rastrear la causa raíz con 5 Whys y comunicar con base en datos y evidencia, no en opiniones
- Hace falta priorizar la evidencia sobre las afirmaciones, y los resultados de experimentos y mediciones sobre la intuición
Who: participantes, responsabilidad y alcance del impacto
- La composición de las personas y perspectivas que participan en definir y resolver el problema (quién está incluido y quién falta) es el punto de partida del pensamiento crítico
- Hay que identificar a las partes interesadas, como ingenieros, PM, usuarios y expertos del dominio, e incluirlas adecuadamente en el proceso de decisión
- Como la mayoría de los problemas afectan a varios equipos y usuarios, hace falta preguntarse primero “¿con quién hay que hablar?” y “¿a quién hay que informar?”
- Para reducir el riesgo de groupthink (pensamiento grupal), donde las opiniones se alinean en una sola voz, hay que atraer deliberadamente perspectivas diversas
- Si se excluye a personas con opiniones opuestas o perspectivas distintas, aumenta el riesgo de que algo se consolide como respuesta correcta sin validar los datos ni los supuestos
- También ayuda a elevar la objetividad traer una mirada externa o gente de fuera del equipo para que vea el problema con “ojos frescos”
- Con la llegada de la IA, se vuelve indispensable separar “¿de quién es la respuesta, de un humano o de la IA?”
- Como un LLM no es más que un motor estadístico, hay que examinar “¿con qué evidencia lo dice?” más que “¿quién lo dijo?”
- El código generado por IA debe tratarse como el código de un interno: la revisión, las pruebas y la validación de adecuación al contexto deben quedar bajo responsabilidad humana
- Al final, también hay que pensar en la responsabilidad y el alcance del impacto (quién responde y quién se ve afectado)
- Aunque un parche urgente satisfaga de inmediato la petición de un gerente, la carga posterior de mantenimiento y respuesta a incidentes puede recaer sobre otros ingenieros o usuarios
- Igual que con el impacto de un cambio de API sobre apps móviles u otros microservicios, siempre hay que considerar “¿quién terminará cargando con las consecuencias de esta decisión?”
What: definir el problema real y recolectar evidencia
- El núcleo del pensamiento crítico es definir con precisión “cuál es el problema real”
- Si llega una solicitud como “agreguemos una función de resumen con IA”, primero hay que preguntar por separado si el objetivo es mejorar la comprensión de datos, reducir la fatiga o algo distinto
- Según si la dificultad del usuario viene de exceso de datos, mala visualización o falta de explicación, la solución puede cambiar por completo
- Como enfatiza Harvard Business Review y otros, dedicar suficiente tiempo a definir el problema reduce el riesgo de gastar recursos en el problema equivocado
- Hace falta escribir explícitamente los requisitos y los criterios de éxito, y acordar “qué estado significa que el problema quedó resuelto”
- Hay que cuidarse conscientemente del plunging-in bias (sesgo de lanzarse de inmediato) de saltar enseguida al “modo resolución”
- Es importante una definición del problema basada en evidencia que reúna hechos concretos más que síntomas
- “El servicio está lento” es una frase ambigua, así que hay que acotar con datos qué página, qué query o qué request es el que está lento
- Hay que revisar logs y métricas con preguntas como “¿qué está lento?”, “¿qué cambió y desde cuándo?” y “¿qué se modificó recientemente?”
- Frente a una solución o conclusión, hay que confirmar una y otra vez “¿qué evidencia respalda esta conclusión?”
- Si la IA señala un null pointer como causa, eso debe verificarse directamente con logs, pruebas y experimentos de reproducción
- Si se afirma que hubo mejora de rendimiento, hay que comprobar si existe una mejora consistente de métricas en varios entornos y varias ejecuciones
- Las respuestas de un LLM deben tratarse en su mayoría como hipótesis plausibles en apariencia, pero sin garantía de exactitud
- Cuando una persona escucha una respuesta “lo bastante convincente”, tiende a dejar de explorar, y esa combinación es especialmente riesgosa
- El pensamiento crítico comienza desde la premisa de que las ideas de la IA, de los colegas y de uno mismo son todas “hipótesis que hay que poner a prueba” y pueden estar equivocadas
Where: conciencia del contexto, entorno y alcance
- Es importante entender dónde ocurre el problema y dónde se aplicará la solución (el contexto)
- Para evitar confundir un pico de CPU en un microservicio específico con una caída general del sistema, hay que ubicar con precisión dónde se produce el incidente
- Según el entorno de ejecución —smartphone del usuario, dispositivo edge o servidor en la nube—, el mismo código puede enfrentar restricciones completamente distintas
- Al depurar, hay que ir acotando “dónde ocurre la falla” siguiendo el flujo de requests y los límites entre componentes
- Hay que separar mediante logs y monitoreo en qué punto surge el problema: cliente, API gateway, backend o base de datos
- Incluso al discutir una idea de funcionalidad, conviene ver en qué etapa del journey del usuario impacta y en qué tramo se concentra la frecuencia de uso
- En experimentos y despliegues también es clave decidir dónde probarlo
- La confiabilidad que se puede obtener y el riesgo cambian según si el experimento se hace en staging, en un entorno interno o sobre una parte del tráfico de producción
- Exponerlo mediante A/B testing a una parte de usuarios reales puede ayudar a descubrir rápido problemas del mundo real, pero también hacen falta mecanismos de contención para limitar el impacto
- Imaginar de antemano dónde podrían aparecer efectos secundarios y hasta dónde podrían propagarse es una marca de un ingeniero experimentado
- Si se cambia una librería compartida, hay que listar los otros servicios y equipos que la usan, y preparar avisos y planes de prueba antes del release
- También hay que revisar el efecto sobre el sistema completo, por ejemplo si la optimización de un módulo aumenta la complejidad de otro o exige cambiar formatos de datos
When: eje temporal y elección de profundidad
- La información sobre “cuándo”, como el momento en que apareció el problema o en que se actuó, es una pista clave para el análisis de causas
- Si se ordena una línea de tiempo con “¿cuándo fue la última vez que funcionaba bien?” y “¿qué cambió después de eso?”, se puede acotar la causa con rapidez
- Es importante el hábito de conectar eventos en horarios específicos —como un nuevo despliegue, un batch nocturno o un cambio de configuración— con el momento del incidente
- Una dimensión del pensamiento crítico en la toma de decisiones es distinguir cuándo conviene profundizar y cuándo basta una heurística
- Si se intenta hacer un análisis completo de todos los problemas, ni el calendario ni los recursos alcanzan; hay que ajustar la profundidad según el riesgo y el impacto
- En una emergencia nocturna, una estrategia realista es restaurar el servicio con una mitigación de corto plazo como reiniciarlo, y luego investigar la causa raíz en horario laboral
- Como muestran casos de NASA, bajo estrés y presión de tiempo la probabilidad de errores de juicio humanos aumenta drásticamente
- Justamente en situaciones donde se necesita decidir rápido, es importante dejar marcado de antemano “hasta dónde esto es una medida temporal” y “a partir de qué punto se debe revisar sí o sí”
- Incluso dejar una nota o ticket de que “esto es una solución temporal y luego se hará análisis de causa y acción correctiva” ayuda a la calidad a largo plazo
- Para mantener el rigor dentro de tiempo limitado, hay que usar priorización y triage
- El tiempo debe asignarse probando primero los supuestos más riesgosos y dejando para después las decisiones menos importantes
- Si en el diseño de una nueva función la validez y el riesgo del algoritmo son mayores, hace falta dedicar antes tiempo a verificar el algoritmo que a los detalles de UI
- El pensamiento crítico también está ligado a reconocer “cuándo pedir ayuda” y “cuándo detenerse y reconsiderar”
- Si no hay progreso después de cierto tiempo, hay que atraer la mirada de otra persona, y conviene fijar puntos deliberados de pausa y revisión, como antes del cierre de sprint o de un release
- Entre la parálisis por análisis y la conclusión apresurada, es importante desarrollar el hábito de revisar si realmente se tiene suficiente información para la decisión actual
Why: profundizar en motivación, causa y fundamento
- Preguntar repetidamente “¿por qué hacemos esto?” funciona como un filtro para descartar modas o imitaciones sin sentido y enfocarse en valor real
- Frente a la adopción de una nueva herramienta de IA o una solicitud para agregar funciones, hay que distinguir con claridad si se busca copiar a la competencia o resolver un problema real del usuario
- Solo si existe una respuesta convincente a “¿por qué es importante?” las numerosas decisiones de detalle durante la implementación podrán mantenerse coherentes
- Cuando surge un problema, es importante bajar de la causa superficial a causas más profundas con la técnica de 5 Whys
- Si baja la precisión del modelo, por ejemplo, hay que rastrear paso a paso causas encadenadas como cambios en la distribución de datos, incorporación de una nueva fuente, falta de validación o falta de monitoreo
- Si la causa final resulta ser una validación insuficiente del pipeline de datos o ausencia de monitoreo, queda claro que reentrenar por sí solo no resuelve el problema de raíz
- En las preguntas de “por qué”, las personas caen con facilidad en sesgo de confirmación y conclusiones apresuradas
- Si la mente se fija en una causa conocida, como una fuga de memoria experimentada antes, es fácil ignorar otras posibilidades como cambios recientes de configuración o de datos
- Para no conformarse con la primera explicación que aparece, hace falta preguntarse “¿hay otra causa posible?” y “¿no hay evidencia que la contradiga?”
- Como se vio en casos empresariales del pasado, entender mal el “por qué” puede impedir durante mucho tiempo corregir caídas de participación de mercado o fallas estratégicas
- Si todo se atribuye solo a factores externos y no se ven problemas internos de proceso, calidad o cultura, se terminan repitiendo remedios equivocados
- Un buen ingeniero mantiene la actitud de preguntar “por qué” con curiosidad humilde y dejando abierta la posibilidad de que sus supuestos estén equivocados
- Incluso cuando cree que una idea va a funcionar, separa “por qué cree eso”, si es por datos o por intuición, y a partir de ahí define cómo validarlo
- Después de decidir, documenta y comparte las razones para que, si el contexto cambia más adelante, se pueda volver a revisar primero el fundamento
How: práctica y comunicación
- La práctica cotidiana del pensamiento crítico puede resumirse en tres ejes: forma de preguntar, validación de evidencia y estructuración de la comunicación
- En lugar de un vago “¿es bueno o malo?”, hay que hacer preguntas concretas y abiertas como “¿qué necesidad del usuario resuelve, cómo la aborda y dónde podría fallar?”
- Es importante el hábito de separar lo que se sabe de lo que no se sabe, y planear cómo se va a experimentar o medir lo desconocido
- Al manejar evidencia, también hay que revisar la posibilidad de interpretaciones alternativas y la entrada de sesgos
- Hay que validar de forma cruzada si el resultado de una sola prueba de rendimiento fue casual o repetible, y si no contradice otras métricas
- Hace falta buscar deliberadamente no solo datos que respalden la propia teoría, sino también datos que la puedan refutar
- A nivel equipo, también se presenta el uso de técnicas como premortem para suponer con anticipación escenarios de fracaso
- Si se asume que el proyecto fracasó y se escriben las razones, se pueden hacer visibles riesgos y supuestos ocultos que se pasaron por alto en la etapa de planificación
- Al comunicar una solución, resulta efectivo estructurar la lógica en el orden definición del problema (What·Why) → solución propuesta (How) → datos y supuestos que la respaldan
- Si se explicitan las premisas y los trade-offs, a los demás les resulta más fácil validar y mejorar la idea, y también es más fácil detectar huecos en la propia lógica
- Presentar primero hechos cuantificables en lugar de opiniones, como “el tiempo de carga de la página mejoró en promedio 25% según el dashboard”, aumenta la confianza
- En entornos donde el pensamiento crítico funciona bien, se forma una cultura de comunicación que da la bienvenida a preguntas y contraargumentos
- Después de una propuesta, se afina la idea preguntando activamente a colegas “¿hay algo que falte en esta lógica?” o “¿hay alguna preocupación?”
- No se trata de una exposición unilateral, sino de un proceso donde varias personas validan juntas la lógica, y eso mismo eleva la calidad de la solución
- A nivel individual, es importante mejorar continuamente el pensamiento mediante retrospectiva y aprendizaje
- Si una decisión apresurada produjo un bug, después hay que hacer una mini retrospectiva para ordenar “qué se pasó por alto y qué se haría distinto la próxima vez”
- También ayuda leer postmortems de otras empresas y materiales sobre sesgos cognitivos para aprender de antemano trampas mentales que conviene evitar en el futuro
Conclusión: el pensamiento crítico como ventaja propiamente humana
- Cuanto más aumenta el uso de la IA, más se consolida el pensamiento crítico no como una opción, sino como una capacidad indispensable
- A través de Who·What·Where·When·Why·How, hay que revisar sistemáticamente personas, problema, contexto, momento, causa y forma de ejecución
- En una cultura de equipo saludable, el pensamiento independiente y la actitud de hacer preguntas se aceptan como algo natural
- Todo el mundo debería poder preguntar “¿esto de verdad resuelve el problema o solo es un parche?”, “¿el usuario realmente quiere esta función?” y “¿los datos realmente muestran una mejora?”
- El pensamiento crítico cumple la función de proteger al equipo de la tentación de las soluciones rápidas tipo parche
- En lugar de tapar el problema por el momento, confirmar la causa raíz y actuar después de validarla es el camino que ahorra tiempo y costo a largo plazo
- Incluso en una era donde la IA y la automatización se encargan de tareas repetitivas y borradores, “resolver el problema correcto, por la razón correcta y de la manera correcta” sigue siendo una tarea humana
- Los equipos que mantengan curiosidad humilde y pensamiento centrado en la evidencia serán los que sigan dando buenos resultados en la era de la IA
Aún no hay comentarios.