La IA no debe reemplazar el pensamiento, sino elevarlo
(koshyjohn.com)- Cuanto más rápido se producen resultados plausibles, más fácil se vuelve repetir sin entender, y si se salta la práctica de desarrollar el criterio, se debilita la capacidad a largo plazo
- En patrones conocidos ayuda mucho, pero ante problemas desconocidos, condiciones ambiguas, información incompleta y restricciones en conflicto, la imitación superficial se derrumba con facilidad y queda expuesto el nivel real
- Un ingeniero sólido delega con gusto tareas mecánicas como boilerplate, resúmenes, scaffolding de pruebas y aceleración de investigación, pero se hace cargo directamente de definir el problema, revisar, elegir y descartar
- El mayor valor de la ingeniería de software está menos en producir código y más en el criterio; se vuelve más importante ver restricciones ocultas, detectar problemas mal planteados y convertir discusiones ambiguas en trade-offs
- Especialmente al inicio de la carrera y en la operación de las organizaciones, es más importante mantener criterios que protejan la comprensión real; cuanto mejor se distingue qué delegar y qué asumir directamente, más se convierte la IA en una herramienta que aumenta el valor humano
Modos de falla que aparecen al subcontratar el pensamiento
- La I.A. resuelve 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 producir resultados convincentes sin comprensión
- Si repites una respuesta generada por la máquina como si fuera tu propio entendimiento, terminas imitando solo la apariencia de competencia sin haber desarrollado capacidades reales
- Cuanto más sustituyes tu comprensión por resultados generados, más te saltas la práctica de formar criterio, y cambias la capacidad a largo plazo por una apariencia útil en el corto plazo
- En situaciones que no se resuelven con plantillas —como problemas desconocidos, condiciones ambiguas, información incompleta o restricciones en conflicto— la imitación superficial se rompe con facilidad
-
La analogía de copiar respuestas en un examen
- Puedes mantener buenas calificaciones copiando respuestas, pero cuando entras a una situación donde de verdad se necesita comprensión, queda claro 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 desconocidos o adaptarse a cambios en las condiciones
- Si reutilizas una y otra vez respuestas que te dio la I.A., solo tomas prestada la apariencia de pericia; la pericia real no se construye
-
La analogía de la calculadora
- Una calculadora es una gran herramienta para ahorrar tiempo, pero si dependes de ella sin sentido numérico, dejas de poder verificar si el resultado tiene sentido
- Un ingeniero con bases puede revisar la salida de la I.A., filtrar errores y corregirla o descartarla
- Un ingeniero sin bases no está usando la I.A.; está siendo arrastrado por la I.A., y eso es aún más peligroso en trabajos donde importan la exactitud y la responsabilidad por 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 un pasajero con acceso a los controles
- En situaciones no estándar —como poca visibilidad, caminos complejos, otros vehículos impredecibles, fallas del sistema o peligros repentinos— es donde se revela la habilidad real
- La I.A. 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 arquitectónicos en competencia, datos parciales, fricción organizacional y trade-offs sin respuesta perfecta
Cómo usan la I.A. los grandes ingenieros
- Los grandes ingenieros no usan menos la I.A.; la usan más activamente, pero sin entregarle el pensamiento mismo
- Delegan con gusto tareas mecánicas como escribir boilerplate, resumir documentación, generar scaffolding de pruebas, proponer refactors, explorar posibles fallas, acelerar investigación y comprimir trabajo repetitivo
- En cambio, formulan preguntas más precisas, definen el problema real en vez de limitarse a la petición inmediata, y priorizan la claridad y la concisión por encima de frases pulidas sin sustancia
- No se limitan a recombinar conocimiento existente dentro del sistema, sino que crean nuevo conocimiento de alto valor
- El tiempo que ganan así lo reinvierten 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 valor más alto no está ahí
- Si lo central fuera solo producir código sintácticamente correcto, la I.A. estaría reemplazando directamente gran parte del trabajo; pero el núcleo real 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 discusiones ambiguas en trade-offs claros, encuentra abstracciones faltantes y no depura solo código, sino también la realidad
- La I.A. puede apoyar estas tareas, pero no puede asumirlas en tu lugar
- En adelante, los ingenieros que generen más valor estarán más cerca de crear principios de diseño, entendimiento del dominio, patrones, contexto y marcos de decisión que hagan a la I.A. más útil
- En este entorno, en vez de ser reemplazado por la I.A., el ingeniero gana más leverage al trabajar por encima de la capa de salida bruta
Un riesgo mayor para ingenieros al inicio de su carrera
- Este problema es especialmente importante al inicio de la carrera
- Los primeros años son el periodo en que se forman capacidades básicas como el sentido para depurar, la intuición de sistemas, la precisión, el criterio estético, la revisión escéptica, la descomposición de problemas y la capacidad de explicar por qué algo funciona
- Estas capacidades se construyen a través de fricción, prueba y error, corrección de fallas, rastreo de causas raíz y del choque con la realidad cuando las cosas no salen como se esperaba
- Si la I.A. elimina toda la dificultad del proceso de aprendizaje, puede darte eficiencia de corto plazo, pero también hacer que te saltes la etapa en que se forjan las capacidades
- Durante uno o dos trimestres puedes parecer eficiente, pero podrías estar perdiendo silenciosamente las habilidades que sostendrán tu futuro
- Los sistemas de apoyo pueden hacer que parezca que algo funciona, pero no pueden crear por ti la capacidad real
No hay atajos para el criterio
- Solo leer explicaciones generadas no hace que la pericia se transfiera a tu cabeza sin hacer el trabajo por tu cuenta
- No existe un camino en el que externalizas el razonamiento durante mucho tiempo y aun así terminas desarrollando una gran capacidad de razonamiento
- Sí es posible y deseable externalizar trabajo mecánico, acelerar la investigación y comprimir tareas repetitivas
- Pero no puedes saltarte el proceso mismo de formación técnica y aun así terminar poseyendo esa técnica
- El error central de la adopción más ingenua de la I.A. está en creer que se está ahorrando tiempo cuando en realidad solo se está aplazando la factura de criterio débil, comprensión superficial y baja adaptabilidad
La línea divisoria y sus implicaciones organizacionales
- Si la I.A. te ayuda a construir comprensión más rápido, a pensar con más profundidad y a trabajar a un nivel más alto, el valor humano aumenta
- Si la I.A. te ayuda a evitar la comprensión, evitar la dificultad y evitar hacerte dueño del razonamiento, el valor humano disminuye
- Un camino se acumula como interés compuesto; el otro vacía el interior y te empuja hacia un estado en el que es fácil volverse irrelevante
- El futuro favorecerá menos a quienes simplemente usan I.A. y más a los ingenieros que distinguen con precisión qué delegar y qué asumir directamente, y convierten el tiempo ahorrado en mejor pensamiento
Por qué afecta aún más a la salud organizacional
- La gestión de ingeniería también queda parada sobre la misma frontera entre usos que aceleran la comprensión y usos que solo la imitan
- Un liderazgo fuerte debe poder distinguir entre resultados pulidos y criterio real; si solo recompensa velocidad, fluidez y capacidad de presentación, perderá de vista 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 trabajo individual, también se debilita el entorno de conocimiento de la organización
- Las revisiones se vuelven más débiles
- 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 juicio técnico de los que depende
- Por eso, lo central no es solo adoptar herramientas de I.A., 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 no la fluidez aparente, sino la comprensión real
- Las entrevistas deben evaluar el proceso de razonamiento más que las respuestas polished
- La evaluación debe recompensar más la claridad, profundidad, buen criterio y contribuciones técnicas duraderas que el volumen de salida
- También tiene un gran impacto en el diseño de equipos y en la cultura
- Hay que evitar que los ingenieros fuertes gasten demasiado tiempo corrigiendo trabajo convincente pero superficial hecho por personas que externalizaron su pensamiento
- Si eso no se evita, los de alto desempeño terminan gastándose como amplificadores para todos los demás, lo que fácilmente deriva en frustración, caída de estándares y salida del equipo
- En la era de la I.A., la calidad organizacional dependerá cada vez más de si el liderazgo puede seguir distinguiendo entre leverage y dependencia, aceleración e imitación, capacidad real y resultados convincentes
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