La IA no debe reemplazar el pensamiento, sino elevarlo
(koshyjohn.com)- Cuanto más rápido se producen resultados convincentes, más fácil es caer en la repetición sin comprensión, y si se omite el entrenamiento que fortalece el criterio, se debilita la capacidad a largo plazo
- Ayuda mucho en patrones conocidos, pero ante problemas desconocidos, condiciones ambiguas, información incompleta y restricciones en conflicto, la imitación superficial se derrumba con facilidad y deja ver la habilidad real
- Los ingenieros sólidos delegan con gusto tareas mecánicas como boilerplate, resúmenes, scaffolding de pruebas y aceleración de investigación, pero se hacen cargo directamente de definir el problema, revisar, elegir y descartar
- El mayor valor de la ingeniería de software está más en el criterio que en la producción de código; se vuelve más importante ver restricciones ocultas, detectar problemas mal planteados y convertir discusiones ambiguas en trade-offs claros
- Especialmente al inicio de la carrera y en la operación de organizaciones, importa más contar con criterios que protejan la comprensión real; cuanto mejor se distingue qué delegar y qué asumir personalmente, más se convierte la IA en una herramienta que aumenta el valor humano
Modos de falla al subcontratar el pensamiento
- La IA procesa rápido tareas como generar código, resumir reuniones, explicar conceptos, redactar borradores de diseño y escribir actualizaciones de estado, pero también puede crear con facilidad el hábito de entregar resultados plausibles sin comprensión
- Si uno repite la respuesta de la máquina como si fuera su propio entendimiento, termina imitando solo una apariencia de competencia sin haber construido capacidad real
- Cuanto más se sustituye la comprensión propia por resultados generados, más se omite la práctica que fortalece el criterio, cambiando la capacidad a largo plazo por una apariencia inmediata
- En situaciones que no se resuelven con plantillas, como problemas desconocidos, condiciones ambiguas, información incompleta o restricciones en conflicto, la imitación superficial colapsa con facilidad
-
La analogía de copiar respuestas en un examen
- Puedes mantener buenas calificaciones copiando respuestas, pero cuando llegas a una situación donde de verdad se necesita comprensión, queda en evidencia que la base está vacía
- Sin la intuición que se acumula al hacer el trabajo por cuenta propia, es difícil razonar sobre problemas no familiares o adaptarse a cambios de condiciones
- Si reutilizas una y otra vez respuestas dadas por la IA, solo tomas prestada la apariencia de experiencia, pero la experiencia real no se acumula
-
La analogía de la calculadora
- Una calculadora es una gran herramienta que ahorra tiempo, pero si dependes de ella sin sentido numérico, dejas de poder revisar si el resultado tiene sentido
- Un ingeniero con bases puede revisar la salida de la IA, filtrar errores y corregirla o descartarla
- Un ingeniero sin bases no usa la IA, sino que termina arrastrado por la IA, y eso es todavía más riesgoso en roles donde importan la precisión y la responsabilidad sobre el resultado
-
La analogía del auto autónomo
- La conducción autónoma reduce la fatiga y resuelve situaciones cotidianas, pero si dependes de ella antes de entender cómo conducir, te acercas más a ser un pasajero con acceso a los controles
- Es en situaciones no estándar —como mala visibilidad, caminos complejos, otros vehículos impredecibles, fallas del sistema o peligros repentinos— donde se revela la habilidad real
- La IA también es fuerte en patrones generales y estructuras conocidas, pero la ingeniería se sale constantemente de eso: cambios de requisitos, bugs sutiles, propiedad poco clara, objetivos de arquitectura en competencia, datos parciales, fricción organizacional y trade-offs sin respuesta perfecta
Cómo usan la IA los grandes ingenieros
- Los grandes ingenieros no usan menos la IA; la usan más activamente, pero sin cederle el pensamiento en sí
- Delegan con gusto tareas mecánicas como escribir boilerplate, resumir documentos, generar scaffolding de pruebas, proponer refactorizaciones, explorar posibles fallas, acelerar investigación y comprimir trabajo repetitivo
- En cambio, formulan preguntas más agudas, definen el problema real en lugar de limitarse al pedido inmediato y priorizan la claridad y la concisión por encima de frases pulidas pero vacías
- No se limitan a recombinar conocimiento existente dentro del sistema, sino que producen nuevo conocimiento de alto valor
- Y reinvierten el tiempo ganado en pensamiento y criterio de mayor nivel
La verdadera fuente del valor
- Durante mucho tiempo se ha equiparado la ingeniería de software con la producción de código, pero el mayor valor no está ahí
- Si lo central fuera solo producir código sintácticamente correcto, la IA terminaría reemplazando directamente una gran parte del trabajo, pero el verdadero núcleo está en el criterio
- Un ingeniero valioso ve restricciones ocultas antes de que provoquen incidentes, detecta que el equipo está resolviendo el problema equivocado, convierte debates ambiguos en trade-offs nítidos, encuentra abstracciones faltantes y no depura solo código, sino la realidad
- La IA puede apoyar este tipo de trabajo, pero no puede hacerse cargo de él en su lugar
- En adelante, los ingenieros que generen más valor estarán más cerca de crear principios de diseño, comprensión del dominio, patrones, contexto y marcos de decisión que hagan más útil a la IA
- En este entorno, en vez de ser reemplazado por la IA, el ingeniero gana más leverage al trabajar en una capa por encima de la salida en bruto
Un riesgo mayor para ingenieros al inicio de su carrera
- Este problema es especialmente importante para quienes están al inicio de su carrera
- Los primeros años son el período en que se forman capacidades fundamentales como intuición de debugging, intuición de sistemas, precisión, criterio estético, revisión escéptica, descomposición de problemas y la capacidad de explicar por qué algo funciona
- Estas capacidades se construyen a través de fricción, ensayo y error, corrección de fallas, seguimiento de la causa raíz y experiencias de chocar con la realidad y ver cómo se rompen las suposiciones
- Si la IA elimina toda dificultad durante el proceso de aprendizaje, puede dar eficiencia a corto plazo, pero hace que se salte la etapa donde se forja la capacidad
- Durante uno o dos trimestres puede parecer eficiente, pero en silencio se puede estar perdiendo la habilidad que sostendrá el futuro
- Puede hacer que un sistema de apoyo parezca funcionar, pero no puede crear por reemplazo la capacidad real
No hay atajos para el criterio
- El simple hecho de leer explicaciones generadas no hace que la experiencia se transfiera a tu mente sin trabajar por tu cuenta
- No existe un camino en el que subcontrates el razonamiento durante mucho tiempo y aun así termines con una gran capacidad de razonamiento
- Sí es posible, y deseable, subcontratar trabajo mecánico, acelerar la investigación y comprimir tareas repetitivas
- Pero no puedes saltarte el proceso mismo de formación de habilidades y aun así terminar poseyéndolas
- El error central del uso más ingenuo de la IA está en creer que se ahorra tiempo cuando en realidad solo se aplaza la factura de un criterio débil, comprensión superficial y baja adaptabilidad
La línea divisoria y sus implicaciones organizacionales
- Si la IA ayuda a construir comprensión más rápido, a pensar con más profundidad y a trabajar a mayor nivel, el valor humano aumenta
- Si la IA ayuda a evitar la comprensión, evitar la dificultad y evitar hacerse dueño del razonamiento, el valor humano disminuye
- Un camino se acumula como interés compuesto; el otro vacía el interior y empuja hacia un estado donde es fácil volverse prescindible
- El futuro favorecerá no a los ingenieros que simplemente usan IA, sino a los que distinguen con precisión qué delegar y qué asumir directamente, y convierten el tiempo ahorrado en mejor pensamiento
Por qué esto pesa aún más en la salud de las organizaciones
- La gestión de ingeniería también queda sobre la misma frontera: distinguir entre usos que aceleran la comprensión y usos que imitan la comprensión
- Un liderazgo sólido debe poder distinguir entre resultados pulidos y criterio real; si solo se recompensa la velocidad, la fluidez y la capacidad de presentación, se pierden las señales de profundidad técnica
- Si se expande el trabajo con baja comprensión y alta fluidez, no solo cae la calidad del output individual, sino que se debilita el entorno de conocimiento de la organización
- Las revisiones se debilitan más
- Las discusiones de diseño se vuelven más superficiales
- La documentación se vuelve más pulida, pero menos útil
- Con el tiempo, la organización pierde la capacidad de producir la claridad y el criterio técnico de los que depende
- Por eso, lo central no es solo adoptar herramientas de IA, sino proteger las condiciones en las que sobreviven el pensamiento real, el aprendizaje y la artesanía técnica
- Desde la etapa de contratación, se necesitan métodos para detectar comprensión real, no solo fluidez aparente
- Las entrevistas deben poner a prueba el proceso de razonamiento más que las respuestas polished
- La evaluación debe recompensar, más que el volumen de output, la claridad, profundidad, criterio sólido y contribuciones técnicas duraderas
- También tiene un gran impacto en el diseño de equipos y en la cultura
- Hay que evitar que los ingenieros fuertes pasen demasiado tiempo arreglando trabajo plausible pero superficial producido por personas que subcontrataron el pensamiento
- Si eso no se evita, los de alto rendimiento terminan gastándose como amplificadores para todos los demás, y el resultado tiende a ser frustración, caída de estándares y fuga
- En la era de la IA, la calidad de una organización dependerá en última instancia aún más de si el liderazgo puede seguir distinguiendo entre leverage y dependencia, aceleración e imitación, capacidad real y output convincente
1 comentarios
Opiniones de Hacker News
Cuanto más releo este argumento, más me gusta la sofisticación de la expresión, pero siento que todavía no llega al nivel de un aforismo
Para convertirse en una frase que le pegue a mucha gente con unas pocas palabras, como "the medium is the message", "you ship your org chart" o "9 mothers can't make a baby in a month", hacen falta años o décadas de ir puliendo el significado
Y como ni siquiera sabemos cómo tratar la formación de significado con RL, la IA no puede hacer eso por nosotros
En realidad la forma original correcta es "9 women can't make a baby in one month"
Aprender haciendo uno mismo. Esa frase me parece más cerca de un aforismo
Intelligence amplification, not artificial intelligence suena bastante bien
Abreviado queda como IA, not AI, y al pasarlo al español se vuelve "AI, no IA", lo cual lo hace todavía más divertido
La IA no puede producirte gusto ni criterio
Si le preguntas a 100 estadounidenses qué significa ese aforismo, probablemente casi nadie captaría correctamente el sentido original de McLuhan
Creo que la IA, en general, puede usarse de dos maneras
Una es como apoyo para escribir código que poseo y entiendo; la otra es usar la IA como una capa de abstracción y dejarle la escritura y el mantenimiento del código
Lo segundo puede estar bien para prototipos, ejemplos o referencias, donde la vida útil es corta y ni la calidad del código ni mi nivel de comprensión importan tanto
El problema aparece cuando en realidad necesitas la opción 1 y usas la 2, engañándote a ti mismo y a los demás
Puede verse rápido y fácil, pero al final terminas hipotecando el codebase, y creo que ahí también empieza el deterioro de capacidades
Las funcionalidades siguen saliendo y por fuera todo se ve bien, pero en cuanto algo explota te das cuenta de que ya ni siquiera puedes depurar tu propio código sin volver a preguntarle al modelo
Hay muchos ingenieros que ya no pueden trabajar sin un IDE moderno, un lenguaje con manejo de memoria, o bibliotecas de GitHub o de un package manager
Por eso, en lo personal, la dependencia de la IA no me parece algo tan esencialmente distinto
El significado de la palabra Engineer también puede cambiar, y de hecho ya existen "web developers" que solo usan Webflow o WordPress
Si nos ponemos estrictos con la definición, entre la gente del área de Software Engineering casi no hay ingenieros certificados de verdad, y en algunos países incluso hay licencia y título formal
Al inicio de la carrera, si había tiempo, probablemente hacía casi cualquier cosa; ahora hay una lista larga de cosas que podría hacer pero no hago porque no me resultan interesantes
No sabemos si la IA costará como una suscripción a Slack, como un miembro más del equipo, o si el servicio desaparecerá y habrá que contratar aparte a alguien con acceso a IA
Así que depender de la IA es bastante distinto a depender de un IDE, que sí puede ser una herramienta local u open source
Una persona con unos 10 años de experiencia ya entiende el flujo y la lógica del código, así que puede usar IA para producir código e incluso mejorar su propia forma de trabajar
En cambio, a los principiantes les pasa fácil que no entienden ni el flujo ni la lógica y se limitan a copiar y pegar, así que no creo que la IA les dé mucho más espacio para pensar
La forma actual de usar IA me resulta más cansada que los últimos 20 años de programación
Lo que más agota es el proceso de plantear el problema, evaluar propuestas, escoger la dirección correcta, descartar sugerencias raras y luego seguir refinando hasta dejarlo casi bien
Después el coding corre entre 1 y 5 horas, y a veces produce un resultado que si lo hubiera hecho yo solo me habría tomado al menos 2 o 3 semanas
Pero después de trabajar así, unas 5 horas centrado en la planificación, quedo totalmente destruido, y ese cansancio es distinto al de hacer programación pura
A veces siento que aprendo algo, pero honestamente también se parece más a trabajo de gerente
Para definir lentamente un problema con un LLM y encontrar una solución plausible, hay que mantener un estado de concentración constante, así que ese flujo de inmersión de antes no aparece tan fácilmente
Hay que procesar una montaña de output y seguir extrayendo lo esencial una y otra vez, y aunque en general esté bien, casi siempre hay algo sutilmente desviado que resulta bastante irritante
Además, por los errores raros y fallas de razonamiento típicos de los LLM, hay que mantener un nivel alto de alerta todo el tiempo, y hasta interpretar ese estilo de comunicación no humano termina agotando
Pero también pienso que el pacing o incluso la procrastination podrían ser, para los humanos, una especie de válvula de alivio de presión
Desde el principio ha habido muchos ingenieros que no piensan bien, y la IA no puede cambiar ese hecho por sí sola
Esa es una de las razones por las que el campo de Software Engineering se ha deteriorado bastante, y la IA tal vez no lo resuelva, sino que solo aplace un caos aún mayor
Incluso quienes sobrevivieron la universidad copiándose necesitaban al final pensamiento crítico para no ser descubiertos y salir adelante
A algunos no les gustará oírlo, pero hasta copiar bien requiere bastante capacidad de pensamiento
Creo que quien le delega a la IA el pensamiento en cualquier nivel es porque originalmente no lo valoraba tanto
Como dice la frase "use it or lose it", y aunque cada vez hay más estudios que la respaldan, siguen apareciendo textos que plantean que usar LLM en desarrollo de software está bien y que nuestro valor sigue estando en la capacidad de pensar
Uno de los encantos de este trabajo es justo ese momento en que, aun estando completamente metido en otra cosa, de pronto se te aparece una solución
Ahora la IA me sirve como una herramienta para convertir rápidamente ese pensamiento en acción
Antes a veces perdía el hilo antes siquiera de poder agarrar una pista; ahora, en pocos minutos desde el teléfono, puedo volver parcialmente real una idea y regresar a lo que estaba haciendo
Es especialmente valioso no tener que preocuparse por perder una idea solo por desviar la mirada un momento
Ahora mismo estoy volviendo a crear numba, y me cuesta imaginar hacer esto solo a mano
Cuando lo intenté hace unos años fue tremendamente doloroso, lento y desordenado
Encima de abstracciones acumuladas durante años había una cantidad interminable de pequeñas cosas
Esta vez lo estoy rehaciendo con LLM, y algo que normalmente tomaría semanas a veces queda resuelto de la noche a la mañana
Aun así, sigo revisando el código yo mismo, también reviso la salida en C generada, y mantengo el control de la arquitectura para que en el futuro tanto yo como el LLM podamos trabajar con ella más fácilmente
No sé bien si esto está reemplazando mi pensamiento
Si hubiera aguantado meses escribiendo y corrigiendo todo a mano, probablemente habría aprendido más sobre compiladores o transpilers, pero entonces me habría quedado atrapado solo en esto
En cambio, ahora hasta me queda tiempo para escribir aparte soporte de servidor NFS para un filesystem personalizado en Golang
Ya tengo montado un sistema donde los agentes encuentran los cambios necesarios para una funcionalidad completa, los desglosan con mucho detalle en la etapa de planificación y luego logran la implementación casi correcta desde el primer intento
En el último año cada vez leo menos código directamente, y a menudo me pregunto si la comodidad que siento con el sistema no será excesiva
He visto tantas veces un nivel tan alto de precisión y tasa de éxito que ya dejé de desconfiar por instinto
Sigo esperando que algún día me queme fuerte, pero curiosamente ese momento no termina de llegar
Claro que hubo pequeñas omisiones y reversions, pero eso ya pasaba antes
La diferencia es que antes el código lo había escrito yo con esfuerzo, así que la relación era mucho más personal
Ahora, cuando surge un problema, en vez de culpar al código termino investigando otra vez por qué el sistema no pudo producir por sí solo la respuesta correcta, o por qué no logró hacer visible todo ese panorama en la planificación antes de implementar
La mayor ventaja de la IA en software es que permite producir código más rápido
Su mayor desventaja es que te tienta a querer producir muchísimo más rápido
Por eso no uso IA en proyectos personales
Porque quiero mantener la mente afilada
Podría haber excepciones si el proyecto trata sobre IA, pero no la uso para escribir ese código
En cambio, el trabajo de la empresa no me preocupa
Si mi manager quiere que haga vibe coding por completo con Claude, simplemente lo hago, porque no soy yo quien paga el costo de la deuda técnica que eso genere