Pensamiento crítico en la era de la Inteligencia Artificial: la perspectiva de un ingeniero de Google

En una época en la que la IA puede programar, generar ideas de diseño y, ocasionalmente, respuestas plausibles bajo demanda, la necesidad del pensamiento crítico humano es mayor que nunca. Incluso la automatización más avanzada no puede reemplazar la capacidad de hacer las preguntas correctas, desafiar supuestos y pensar de manera independiente en este momento.

Este ensayo explora la importancia de las habilidades de pensamiento crítico para ingenieros de software y equipos técnicos utilizando el marco clásico de “Quién, qué, dónde, cuándo, por qué y cómo” para estructurar una guía pragmática.

Quién: No confíes en la IA como un oráculo. Verifica su salida.
Qué: Define el problema real antes de apresurarte hacia una solución.
Dónde: El contexto es fundamental. Un arreglo que funciona en un entorno aislado puede fallar en producción.
Cuándo: Conoce cuándo usar una heurística rápida vs. un análisis profundo.
Por qué: Usa la técnica de los “5 Porqués” para descubrir causas subyacentes.
Cómo: Comunícate con evidencia y datos, no sólo con opiniones.

Profundizaremos en cómo cada una de estas categorías de preguntas se aplica a la toma de decisiones en un mundo aumentado por IA, con ejemplos concretos y errores comunes. El objetivo es mostrar cómo la curiosidad humilde y el razonamiento basado en evidencia pueden mantener los proyectos en curso y evitar problemas posteriores.

Quién: involucrar a las personas y perspectivas correctas

¿Quién está involucrado en definir o resolver el problema? En proyectos técnicos, el pensamiento crítico comienza por identificar el “quién”. Esto significa saber quiénes son los stakeholders (por ejemplo, ingenieros, gerentes de producto, usuarios, expertos del dominio) y asegurarse de que las personas adecuadas participen en la toma de decisiones. Los problemas en ingeniería rara vez se resuelven de forma aislada: afectan a los usuarios y, a menudo, abarcan múltiples equipos. Un pensador crítico se pregunta: ¿A quién debemos consultar o informar? ¿Quién podría tener experiencia relevante o una perspectiva diferente? Incluir diversos puntos de vista es esencial.

De lo contrario, los equipos corren el riesgo de caer en el groupthink, donde todos convergen en la misma idea y las opiniones disidentes se silencian. El groupthink puede engañar a un equipo para que valide sólo sus ideas alineadas sin cuestionar si se basan en buenos datos o supuestos sólidos. Para contrarrestarlo, los equipos eficaces fomentan preguntas de todos los miembros e incluso incorporan personas externas para obtener ojos frescos. En resumen, quién está en la sala (y quién no) puede determinar la objetividad de las decisiones técnicas.

¿A quién debemos escuchar: humanos o IA? En la era de los asistentes de IA, también debemos evaluar críticamente de quién proviene una respuesta. ¿Es la salida de un modelo de lenguaje o de un colega experimentado? Una IA puede proporcionar una respuesta que suena válida, pero recuerda que es un motor estadístico. Quién “dijo” algo importa.

Un pensador crítico trata la salida de una IA como una entrada más para examinar, no como un oráculo. Si una entidad (como una IA) nos entrega una respuesta que suena plausible, nuestra tendencia humana es aceptarla y no profundizar. Esta pereza cognitiva no es nueva: es una debilidad humana general elegir la solución que “suena bien” y seguir adelante. Pero en ingeniería, confiar ciegamente en una respuesta puede ser peligroso. Si un asistente de IA sugiere un fragmento de código o una arquitectura, pregúntate: ¿Quién lo generó? ¿Entiende realmente el contexto? Trata la salida de IA como si viniera de un pasante sin experiencia: verifica todo.

Por ejemplo, si Cursor proporciona una solución para un error, un ingeniero crítico revisaría ese código minuciosamente y lo probaría, tal como revisaría el trabajo de un desarrollador junior. La pregunta “quién” nos recuerda que la responsabilidad y la comprensión recaen en los humanos, independientemente de la participación de la IA.

¿Quién es responsable y quién se ve afectado? Finalmente, el pensamiento crítico significa mantenerse consciente de quién se verá afectado por las decisiones técnicas. Lanzar una solución rápida y desordenada puede satisfacer a un gerente a corto plazo, pero ¿quién mantendrá el código más adelante? Si un sistema falla, ¿quién soporta el costo: los usuarios finales, los ingenieros de guardia, la reputación de la empresa?

Considerar el impacto humano nos mantiene anclados en la realidad. Fomenta la humildad: reconocer que nuestras decisiones afectan a personas reales y que no tenemos todas las respuestas. Los grandes ingenieros y profesionales de producto cultivan esta humildad. Saben que siempre hay más que aprender y que ninguna persona tiene la imagen completa. Adoptar una postura de aprendizaje y hacer preguntas a los colegas les permite llenar vacíos de conocimiento y detectar errores temprano.

En la práctica, esto puede significar que un desarrollador backend verifique el impacto de una función con un compañero frontend (“¿Este cambio en la API podría romper la aplicación móvil?”) o que un desarrollador busque una revisión de seguridad en el equipo de infosec en lugar de asumir que “probablemente está bien”. En resumen, el pensamiento crítico en equipos es un esfuerzo social: prospera cuando el “quién” incluye una mezcla de personas dispuestas a cuestionarse entre sí y a sí mismas.

Qué: definir el problema real y recopilar evidencia

¿Qué problema estamos realmente tratando de resolver? Esta es quizás la pregunta más importante. Una trampa clásica en ingeniería es apresurarse a resolver algo sin confirmar que es lo correcto. De hecho, la Harvard Business Review ha enfatizado que definir rigurosamente el problema desde el principio garantiza que abordemos los desafíos adecuados y evitemos esfuerzos desperdiciados. En la práctica, esto significa tomarse tiempo para aclarar requisitos y criterios de éxito. Imagina el caso: un gerente de producto solicita “una función de IA para resumir datos de usuarios”. Ir directamente a codificar un algoritmo de resumen sería prematuro antes de preguntar cuál es el objetivo final. ¿Es ayudar a los usuarios a entender tendencias? Si es así, tal vez el “problema real” es que los usuarios están abrumados por datos sin procesar, y la solución podría ser una mejor visualización, no un resumen.

El pensamiento crítico nos insta a articular el problema y cuestionar supuestos iniciales. Nuestra tendencia natural es entrar en “modo solución” de inmediato, pero esto suele llevar a arreglos rápidos y superficiales en lugar de soluciones estratégicas y reflexivas. Si no nos detenemos a definir qué necesita resolverse, corremos el riesgo de arreglar un síntoma o un problema mal entendido. Un ingeniero reflexivo preguntará: “¿Cómo sabemos que estamos resolviendo el problema correcto?”—una pregunta simple que puede ahorrar mucho tiempo y evitar dolores de cabeza posteriores.

Concretamente, definir qué es el problema implica recopilar evidencia y hechos. Por ejemplo, si los usuarios se quejan de que el sistema es “lento”, en lugar de optimizar código al azar, un pensador crítico preguntará: ¿Qué es exactamente lento? ¿El tiempo de carga, una consulta específica o toda la app? ¿Qué evidencia tenemos? Tal vez los registros muestran que una consulta tarda 5 segundos. Esto enmarca claramente el problema: mejorar esa consulta. Del mismo modo, en escenarios de debugging, preguntar “¿Qué cambió?” cuando algo se rompió a menudo apunta a la causa: un despliegue reciente o una actualización de configuración. Esta mentalidad investigativa garantiza que abordemos la causa real, no la primera suposición.

¿Qué evidencia respalda nuestra solución o conclusión? El pensamiento crítico en ingeniería se basa fundamentalmente en la toma de decisiones basadas en evidencia. No basta con tener una idea: debemos justificarla con datos o razonamiento lógico. Siempre pregunta: “¿La evidencia respalda esta conclusión?”

Por ejemplo, si un modelo de IA sugiere que un error se debe a un null pointer exception, no lo aceptes sin más: revisa los logs o escribe una prueba unitaria para confirmarlo. Si una prueba de rendimiento indica mejora, verifica los resultados en múltiples ejecuciones o entornos. En el desarrollo asistido por IA moderno, esto es especialmente vital.

Los modelos de lenguaje (LLM) suelen producir respuestas que suenan correctas. Son excelentes para sonar seguros, lo que puede engañar incluso a ingenieros experimentados.

Si alguna entidad te da un resultado suficientemente bueno, probablemente no vas a pasar mucho tiempo mejorándolo a menos que haya una buena razón. De la misma manera, probablemente no vas a investigar algo que la IA te dice si suena plausible. Esto es una debilidad, pero es una debilidad general de la cognición humana, no de la IA en sí misma. – Hacker News.

Sin embargo, una respuesta plausible no es necesariamente verdadera. Las respuestas de los LLM son “casi siempre” plausibles, pero sin garantía de exactitud, una falla con consecuencias reales. Un pensador crítico trata cualquier solución propuesta (ya sea de una IA o un compañero) como una hipótesis a probar, no como un hecho. Recopila evidencia para confirmarla o refutarla. Esto puede implicar ejecutar un experimento, recolectar métricas o buscar incidentes pasados similares.

Considera el ejemplo de evaluar un fragmento de código generado por IA. Supongamos que Cursor proporciona una solución para conversiones de zonas horarias. En lugar de copiar y pegar asumiendo su validez, un desarrollador crítico lo prueba con varios formatos y casos límite. Si descubre que el código falla en offsets complejos, esa evidencia dicta el siguiente paso: quizá usar una biblioteca dedicada. Al preguntar “¿Qué datos respaldan esto?”, los ingenieros evitan la trampa del sesgo de confirmación.

En lugar de ello, buscan activamente evidencia que pueda refutar su idea. En los debates técnicos, el sesgo de confirmación puede llevar a alguien a defender su elección inicial e ignorar alternativas. El antídoto es buscar datos o comentarios que desafíen tu idea: si crees que una nueva función mejoró el tiempo de carga, también revisa si lo empeoró en algún caso. Lo que sabemos (y lo que no) debe guiar las decisiones, no sólo lo que sentimos. Los buenos pensadores críticos son casi científicos: recopilan hechos, ejecutan pruebas y dejan que la evidencia, no el ego, determine el camino.

Dónde: considerar contexto y alcance

¿Dónde ocurre este problema y dónde se aplicará una solución? El contexto lo es todo en ingeniería. Una solución que funciona perfectamente en un entorno puede fallar en otro. Pensar críticamente significa ser consciente de dónde se cumplen nuestras suposiciones. Los ingenieros deben preguntarse: ¿Dónde está el límite de este problema? ¿Dónde en el sistema o flujo de trabajo estamos viendo los efectos?

Por ejemplo, si una herramienta de operaciones de IA detecta una anomalía en las métricas del sistema, debemos localizar dónde —qué servidor, qué módulo— antes de reaccionar. Un pico en el uso de CPU de un microservicio no significa que todo el sistema esté fallando. Al localizar dónde se encuentra el problema, evitamos generalizar demasiado o desplegar “soluciones” globales innecesarias. De manera similar, considera dónde se usará la solución. ¿El código se ejecutará en un smartphone de bajo rendimiento o en un servidor potente en la nube? El contexto podría dictar enfoques muy diferentes. Un pensador crítico siempre es consciente del entorno: “¿Dónde se ejecutará este código? ¿Dónde los usuarios encuentran dificultades?”

¿Dónde están las lagunas en nuestro conocimiento? Preguntar “dónde” también significa identificar dónde necesitamos más información. Si estamos depurando un sistema distribuido, podríamos darnos cuenta de que no sabemos dónde falla una solicitud específica: ¿es en el cliente, en el API gateway, o en la base de datos? Esto es una señal para recopilar más datos (por ejemplo, agregar registro en varios puntos) para determinar la ubicación de la falla. Del mismo modo, si se discute una idea de producto, el pensamiento crítico nos insta a preguntar dónde encaja esta idea en el recorrido del usuario. Esto previene resolver un problema inexistente; quizá la “función genial” apunta a una parte de la aplicación que los usuarios rara vez visitan. Conocer dónde ayuda a asignar esfuerzos a donde más importa.

Por ejemplo, imagina planificar un experimento para el lanzamiento de una nueva función. Una pregunta crítica es: ¿Dónde vamos a probarlo —en un entorno de staging, con usuarios internos o como prueba A/B con un pequeño porcentaje en producción? Cada contexto tiene pros y contras. Probar en un entorno realista (como un pequeño porcentaje de usuarios reales) puede revelar problemas que una prueba aislada no mostraría. Por otro lado, algunos experimentos deben permanecer en un sandbox para evitar afectar a los usuarios reales. Al considerar explícitamente dónde se realiza un experimento, los ingenieros aseguran un enfoque de pruebas con rigor adecuado según las limitaciones. Es fácil obtener confianza falsa de un resultado perfecto en laboratorio que no se sostiene en el mundo real.

Finalmente, “dónde” puede ser metafórico: ¿Dónde podría esta solución causar efectos secundarios? ¿Dónde podría esta decisión tener impacto posterior? Pensar unos pasos adelante es una característica de ingenieros experimentados. Por ejemplo, al modificar una biblioteca compartida, pregúntate dónde más se usa esa biblioteca. De esta manera, anticipas efectos en cadena y puedes verificar esos lugares o alertar a los equipos antes de que ocurran problemas. En resumen, la conciencia contextual —espacial, ambiental y sistémica— es parte clave del pensamiento crítico. Previene la visión de túnel. Los grandes ingenieros no sólo resuelven un problema; lo resuelven en el lugar correcto y con plena conciencia del entorno.

Cuándo: tiempo, cronogramas y cuándo profundizar

¿Cuándo ocurrió o ocurrirá algo? La dimensión temporal es crucial en el trabajo técnico. Pensar críticamente implica preguntarse cuándo, tanto al diagnosticar problemas como al planificar el trabajo. En la resolución de problemas, entender cuándo apareció un error por primera vez o cuándo un sistema se comporta de manera diferente a menudo revela la causa. (“El sistema se cayó a las 3 a.m. de anoche: ¿qué ocurrió alrededor de esa hora?” Quizá un nightly job o un despliegue coincidió con la falla). Los ingenieros experimentados acostumbran preguntar: “¿Cuándo funcionó por última vez? ¿Qué ha cambiado desde entonces?” Esta línea de cuestionamiento suele ser más efectiva para encontrar la causa raíz que adivinar a ciegas. Esto se vincula con la recopilación de evidencia: un cronograma de despliegue o el historial de versiones puede mostrar exactamente cuándo se activó un código defectuoso.

¿Cuándo debemos aplicar más rigor y cuándo es suficiente una heurística rápida? No toda decisión justifica días de análisis; parte del pensamiento crítico es saber cuándo profundizar. En ingeniería, equilibramos constantemente la exhaustividad con las limitaciones de tiempo. Plazos de proyecto y incidentes de guardia pueden generar enorme presión para actuar rápido. Bajo estrés o cronogramas ajustados, los humanos tienden a depender de la intuición y atajos mentales —lo que los científicos cognitivos llaman heurísticas. Son útiles, pero también abren la puerta a sesgos y errores.

Investigaciones de la NASA han notado que cuando los ingenieros están bajo estrés o tienen tiempo limitado, toman decisiones más rápidas y propensas a errores que las tomadas con tiempo para reflexionar. Esto no significa que siempre podamos evitar la urgencia, sino que debemos reconocer el riesgo. Un pensador crítico bajo presión temporal desacelerará conscientemente los aspectos más cruciales de la decisión. Por ejemplo, si estás depurando una caída en producción a las 2 a.m., podrías aplicar una solución rápida para que el sistema funcione (eso es una heurística, p. ej., reiniciar un servicio). Pero la mentalidad crítica significa también anotar: “Esto es un parche temporal. Necesito investigar la causa raíz por la mañana.” En otras palabras, sabe cuándo aplicar un arreglo temporal y cuándo invertir en una solución permanente.

Abordar el rigor con tiempo limitado a menudo implica triaje: priorizar qué preguntas necesitan respuestas profundas ahora y cuáles pueden resolverse después. Un buen impulso es: “¿Cómo abordamos esto con rigor dadas las limitaciones de tiempo?” Por ejemplo, al planificar una nueva función con un plazo ajustado, el pensamiento crítico puede llevar a un equipo a identificar la suposición más riesgosa y probarla temprano (aunque sea de manera rápida y sencilla), en lugar de perfeccionar cada detalle. Se enfocan en cuándo se necesita cada información. ¿Está bien decidir la interfaz de usuario más tarde, pero es crucial validar el algoritmo ahora? Si es así, se asigna el tiempo acorde.

Los buenos pensadores críticos también desarrollan sentido del tiempo para intervenciones. ¿Cuándo pedir ayuda? Si un problema permanece sin resolver después de cierto tiempo, un ingeniero crítico sabe que podría ser momento de conseguir una segunda opinión o escalar la discusión al equipo completo. ¿Cuándo debemos pausar y reconsiderar? En equipos Agile, esto puede ser al final de un sprint o antes de grandes lanzamientos, básicamente puntos de control “cuándo” integrados para preguntar si van por buen camino. ¿Y cuándo hemos hecho suficiente análisis? Existe un punto de rendimientos decrecientes.

Ser riguroso no significa paralizarse por análisis. Significa hacer la cantidad correcta de reflexión para la decisión que se enfrenta. Por ejemplo, si tienes un día para depurar un problema, dedicar las primeras 4 horas a recopilar datos metódicamente es sensato; gastar 23 horas para obtener la respuesta perfecta podría significar perder el plazo. El pensamiento crítico ayuda a equilibrar esto mediante la autoconciencia: saber cuándo caes en parálisis por análisis y cuándo estás saltando a conclusiones demasiado pronto.

Por qué: cuestionar motivos, causas y fundamentos

¿Por qué estamos haciendo esto? Las preguntas “por qué” van al corazón de la motivación y la causalidad. En un contexto de ingeniería, preguntar constantemente por qué cumple dos grandes propósitos: (1) asegurar que haya un fundamento sólido para las acciones (para no hacer cosas sólo porque “alguien lo dijo”), y (2) profundizar para encontrar la causa raíz de los problemas en lugar de tratar los síntomas. Un pensador crítico frente a una tarea —por ejemplo, implementar una nueva herramienta de IA— preguntará: “¿Por qué necesitamos esta herramienta? ¿Qué problema resolverá y por qué es importante?”

Si la mejor respuesta del equipo es “porque está de moda” o “nuestro competidor la tiene”, eso debería generar preocupación. Perseguir palabras de moda sin un claro por qué puede llevar a invertir en soluciones que no satisfacen realmente las necesidades de los usuarios. Por otro lado, articular un por qué sólido (p. ej., “reducir el tiempo que los usuarios dedican a analizar sus datos automatizando resúmenes”) alinea al equipo con el objetivo real. Fomenta el pensamiento independiente: un ingeniero que comprende el por qué puede tomar mejores decisiones de manera autónoma durante la implementación, porque entiende profundamente la meta final y no sólo sigue órdenes.

¿Por qué ocurrió esto? Cuando algo sale mal (o bien), preguntar “por qué” repetidamente es una técnica probada para ir más allá de respuestas superficiales. De hecho, la técnica de los Cinco Porqués en análisis de causa raíz es, esencialmente, pensamiento crítico institucionalizado: te obliga a desentrañar causas capa por capa. La idea es evitar saltar a la primera explicación y, en su lugar, descubrir la cadena de causalidad.

Por ejemplo, imagina que la precisión de un modelo de aprendizaje automático cae repentinamente. Una respuesta ingenua podría ser: “El modelo es malo, reentrenémoslo.” Un enfoque crítico preguntaría: “¿Por qué bajó la precisión? Porque cambió la distribución de los datos de entrada.” ¿Por qué sucedió eso? Tal vez se agregó una nueva fuente de datos. ¿Por qué no se tuvo en cuenta? Quizá la canalización de datos carecía de validación para cambios en la distribución. Al preguntar “por qué” cinco veces (o las necesarias), probablemente obtengas un panorama mucho más claro: quizá la causa raíz real era un proceso de monitoreo defectuoso que no detectó a tiempo el data drift.

La diferencia es enorme: un arreglo rápido podría sólo reentrenar el modelo (tratando el síntoma de baja precisión temporalmente), pero el enfoque de los Cinco Porqués podría llevarte a mejorar el sistema de monitoreo, evitando que el problema vuelva a ocurrir. Como explica una guía sobre los 5 Porqués, este método “busca llegar al núcleo del asunto en lugar de sólo abordar síntomas superficiales”, animando a los equipos a pasar de soluciones rápidas a soluciones sostenibles.

Sin embargo, el “por qué” puede ser un arma de doble filo si no se tiene cuidado. Los humanos son propensos a sesgos al responder por qué. Una trampa común es el sesgo de confirmación: podríamos aferrarnos a una explicación conveniente que encaje con nuestras ideas preconcebidas y dejar de investigar. Por ejemplo, un ingeniero podría asumir: “El servidor se cayó por una fuga de memoria, que ya ocurrió antes,” y no considerar otras causas como un cambio de configuración reciente, simplemente porque la fuga de memoria encaja con su modelo mental. Si no busca evidencia para refutar su hipótesis, podría perder la causa real.

El sesgo mencionado de “zambullirse” es otra trampa del por qué: la tendencia a apresurarse a resolver un problema percibido sin entenderlo completamente. Estudios han encontrado que este sesgo —saltar a conclusiones e imponer soluciones predefinidas— lleva a tratar síntomas en lugar de causas raíz en aproximadamente la mitad de las decisiones fallidas estudiadas. Es decir, no preguntar suficientemente “por qué” (o no el correcto) puede hundir proyectos. La empresa Harley-Davidson en los años 80 diagnosticó mal por qué estaban perdiendo cuota de mercado, culpando a factores externos y aplicando soluciones incorrectas, cuando los problemas reales eran internos. Tomó años corregir el rumbo, ejemplificando cómo no precisar el verdadero “por qué” prolonga los problemas.

Los buenos pensadores críticos son casi implacablemente curiosos sobre el por qué. Mantienen una curiosidad humilde —abiertos a descubrir que su suposición inicial estaba equivocada. Preguntan cosas como: “¿Por qué creemos que este enfoque funcionará? ¿Es por datos reales o sólo intuición? ¿Por qué los usuarios piden esta función —cuál es la necesidad subyacente?” Al profundizar en las razones, a menudo detectan brechas lógicas o requisitos ocultos. Es importante también comunicar el por qué de las decisiones a otros, lo que ayuda a los equipos a mantenerse alineados y detectar fallas. Si no puedes explicar claramente por qué se tomó una decisión técnica, eso es una señal de alerta: o la decisión carece de razonamiento sólido o este no se comparte (ambos peligrosos). Por el contrario, cuando todos comprenden la razón (el por qué), pueden verificar de manera independiente si nuevos desarrollos aún la respaldan o si debe revisarse.

Cómo: aplicar rigor y comunicar claramente

Después de explorar “quién, qué, dónde, cuándo, por qué”, la pregunta final es: “¿Cómo practicamos realmente el pensamiento crítico día a día?” Esto se refiere a los métodos y la mentalidad: cómo abordar problemas con rigor pero de manera eficiente, y cómo llevar soluciones a cabo con comunicación clara. Los buenos pensadores críticos tienden a tener un enfoque sistemático. Formulan preguntas de manera clara, validan la evidencia y comunican soluciones de forma lógica. Desglosemos esto:

¿Cómo abordar problemas de manera metódica? A menudo empieza por hacer mejores preguntas. En lugar de consultas vagas, hacen preguntas específicas y abiertas que conducen a información valiosa. Por ejemplo, en lugar de “¿Es bueno este diseño?”, un pensador crítico podría preguntar: “¿Cómo satisface este diseño la necesidad principal del usuario y cómo podría fallar?” Es importante evitar preguntas tendenciosas o dirigidas que sólo confirmen lo que ya pensamos. Mantener la mente abierta y profundizar en los detalles produce información mucho más útil.

Un hábito práctico es enumerar lo que se sabe y lo que no se sabe, y luego planear cómo probar o aprender lo desconocido. Piensa como un científico: si tienes una hipótesis (p. ej., “la base de datos es el cuello de botella”), descubre cómo probarla o refutarla (quizá mediante profiling o revisando los tiempos de consulta). Esta interrogación estructurada de los problemas está en el núcleo del pensamiento crítico.

¿Cómo validar evidencia y evitar sesgos? Una vez que tienes datos o respuestas, un pensador crítico los valida. ¿Los datos realmente respaldan la conclusión o hay interpretaciones alternativas? Esto puede implicar comparar métricas de dos fuentes, reproducir un error en un entorno de prueba para asegurarse de que no sea un caso aislado, o pedir una revisión de código sobre una suposición que hayas hecho. También significa ser consciente de tus propios sesgos.

Como se mencionó antes, si notas que te inclinas hacia una explicación demasiado rápido, haz una pausa y pregunta: “¿Estoy considerando toda la evidencia, o sólo los datos que confirman mi teoría?” Una estrategia es buscar activamente evidencia contradictoria. Si crees que una nueva función mejoró la retención, observa cualquier cohorte donde la retención no haya mejorado: ¿qué es diferente allí? Al aceptar datos negativos, te aseguras de no engañarte a ti mismo. Esto es esencialmente una mentalidad de aseguramiento de calidad aplicada al pensamiento: prueba la solidez de tus ideas como pruebas tu código.

Además, marcos de trabajo y listas de verificación ayudan a mantener el rigor. Algunos equipos, por ejemplo, usan ejercicios de premortem (imaginar un futuro donde el proyecto falla y anotar las razones) para identificar problemas potenciales y suposiciones que no se consideraron inicialmente. Estas técnicas promueven una evaluación más crítica del plan antes de ejecutarlo.

¿Cómo comunicar soluciones y razonamiento? Una solución brillante no vale mucho si no puede ser comunicada ni implementada por el equipo. El pensamiento crítico brilla en cómo se explican las soluciones. Los buenos ingenieros organizan su explicación lógicamente: comienzan con la definición del problema (el qué y el por qué), presentan la solución propuesta (el cómo) y proporcionan la evidencia o razonamiento que la respalda. Hacen explícitas sus suposiciones y describen los trade-offs considerados.

Este tipo de comunicación no sólo ayuda a los demás a entender la propuesta, sino que también sirve como un último auto-chequeo para el pensador: si no puedes articularlo claramente, quizá tu pensamiento aún no está claro. Es importante que los pensadores críticos utilicen hechos y datos para reforzar su comunicación, en lugar de exageraciones u opiniones. Como señala un artículo de liderazgo en ingeniería, los ingenieros humildes prefieren hechos sobre opiniones: citan los datos (“este cambio mejoró el tiempo de carga en un 25 % según el tablero”) en lugar de hacer afirmaciones grandilocuentes. Este enfoque construye credibilidad. Muestra que estás guiado por la evidencia, lo que facilita que colegas y partes interesadas confíen en la solución.

Además, la comunicación clara implica escuchar e invitar retroalimentación. Un pensador crítico no da un monólogo; anima a otros a cuestionar y hacer preguntas, porque ese escrutinio validará la idea o ayudará a mejorarla. En reuniones, esto podría verse así: “Esto es lo que propongo y por qué. ¿Alguien ve algún hueco en este razonamiento o tiene preocupaciones?” Fomentando un diálogo abierto, aseguran que la solución sea sólida y consensuada, no solo que gane la voz más fuerte.

¿Cómo mejorar continuamente nuestro pensamiento crítico? La meta-pregunta es: “¿Cómo aseguramos que estamos mejorando continuamente nuestro pensamiento crítico?” La respuesta es práctica y reflexión. Así como hacemos retrospectivas de proyectos, realizar mini-retrospectivas sobre decisiones puede agudizar las habilidades de pensamiento. Por ejemplo, si una decisión apresurada llevó a un error, el equipo puede analizar: ¿cómo lo pasamos por alto y cómo podemos evitarlo la próxima vez?

Con el tiempo, los ingenieros construyen una biblioteca mental de lecciones aprendidas (p. ej., “recordar verificar X, porque la última vez asumimos y nos salió mal”). Muchos ingenieros de alto nivel también cultivan hábitos como leer post-mortems de fracasos de otras compañías o estudiar sesgos cognitivos para familiarizarse con trampas potenciales. El pensamiento crítico no es un requisito que se marca una sola vez; es una disciplina continua a lo largo de la carrera, basada en curiosidad, humildad y evidencia.

Conclusión

A medida que la IA se utiliza cada vez más, el pensamiento crítico no es opcional, sino esencial. Debemos preguntarnos: quién debe estar involucrado, cuál es el verdadero problema, dónde está el contexto, cuándo profundizar, por qué se hace algo y cómo hacerlo correctamente. Al usar este marco clásico de manera pragmática, los equipos técnicos pueden navegar la complejidad con claridad.

Implica una cultura donde se valora el pensamiento independiente: los miembros del equipo se sienten seguros para cuestionar una solución propuesta (“¿Cómo sabemos que esto es realmente la solución y no solo un parche?”), desafiar suposiciones (“¿Por qué estamos seguros de que los usuarios quieren esta función?”) y exigir evidencia (“¿Los datos realmente muestran una mejora o estamos viendo lo que queremos ver?”). Adoptar una curiosidad humilde —la idea de que, sin importar nuestra experiencia, podríamos estar perdiendo algo— evita que los ingenieros caigan en sesgo de confirmación o exceso de confianza.

El pensamiento crítico también protege frente a la tentación de soluciones rápidas. Es comprensible querer parchear un problema y seguir adelante, especialmente bajo presión. Pero, como hemos visto, no pensar críticamente sobre un parche puede hacer que el mismo problema resurja o, peor, que solucionemos lo incorrecto. Al plantear preguntas difíciles desde el principio y validar antes de actuar, en realidad ahorramos tiempo y problemas a largo plazo. Evitamos problemas posteriores detectándolos temprano, ya sea descubriendo un fallo de diseño antes de escribir código o detectando que la salida de una IA es defectuosa antes de que llegue a los clientes.

En conclusión, aunque la IA y la automatización seguirán evolucionando y manejando tareas rutinarias, el pensamiento crítico sigue siendo una ventaja exclusivamente humana. Es la forma de asegurarnos de que estamos resolviendo los problemas correctos, de la manera correcta, por las razones correctas.

Texto tomado y traducido del blog Élevate
Addy Osmani, Critical Thinking during the age of AI. Who, what, where, when, why, how