29 puntos por GN⁺ 2026-02-05 | 9 comentarios | Compartir por WhatsApp
  • Con la llegada de las herramientas de codificación con IA, la experiencia de pensar profundamente se ha reducido de forma drástica, y siento que mi crecimiento como ingeniero se ha estancado
  • De las dos facetas que hay en mí, el 'Builder' y el 'Thinker', el Builder está satisfecho gracias a la IA, pero el Thinker está hambriento
  • Con el "vibe coding" se puede pasar rápido de la idea a la realidad, pero las oportunidades de resolver problemas de forma creativa han disminuido mucho
  • Cuando la IA ofrece una solución "suficientemente buena" al nivel de un 70%, por mi tendencia pragmática me resulta difícil rechazarla
  • Intenté encontrar fuera de la programación la satisfacción de pensar profundamente, pero no lo logré, y sigo en una situación de incertidumbre sobre si podré satisfacer ambas necesidades al mismo tiempo

Un planteamiento sobre la carencia de pensamiento

  • Antes de leer, piensa: “¿cuándo fue la última vez que pensaste seriamente?”
  • Este texto no ofrece soluciones ni consejos; es simplemente una descarga de la frustración que he sentido últimamente

Dos inclinaciones: Builder y Thinker

  • Builder: la inclinación a construir, lanzar y producir resultados prácticos
    • Está motivado por la velocidad y la utilidad
    • Encuentra placer en la dopamina de un despliegue exitoso, en la satisfacción de crear sistemas que resuelven problemas reales, y en saber que alguien está usando sus herramientas
  • Thinker: la inclinación que necesita una lucha mental profunda y prolongada
    • En la universidad, cuando estudiaba física, nos daban problemas de tareas muy por encima de la dificultad promedio
    • Había problemas en los que, aunque entendieras los conceptos, era difícil siquiera imaginar un enfoque

Tres tipos de estudiantes frente a problemas difíciles

  • Tipo 1 (la mayoría): lo intenta unas cuantas veces, se rinde y pide ayuda al profesor o al asistente
  • Tipo 2 (perfil investigador): va a la biblioteca, busca problemas parecidos o pistas, y transforma el problema en algo resoluble; por lo general, llega a la solución
  • Tipo 3 (perfil Thinker): se acerca al problema únicamente pensando
    • Durante días o semanas, dedica casi todo su tiempo mental no-I/O a la posibilidad de resolverlo
    • El pensamiento continúa incluso mientras duerme
    • Este método nunca le falló, y llegó a reconocer que pensar en profundidad y durante mucho tiempo era una fortaleza propia
    • No era tan rápido ni tan talentoso por naturaleza como el 1% superior, pero tenía la convicción de que, con suficiente tiempo, podía resolver cualquier problema

El conflicto con la IA

  • La razón por la que la ingeniería de software me resultaba tan satisfactoria al principio era justamente esta doble satisfacción
  • Satisfacía tanto al Builder (crear algo útil y sentirse productivo y práctico) como al Thinker (resolver problemas realmente difíciles)
  • Los proyectos en los que más crecí como ingeniero siempre incluían muchos problemas difíciles que exigían soluciones creativas
  • Pero últimamente han disminuido de forma drástica las ocasiones en que paso varias horas o más pensando seriamente en un solo problema
  • Creo que la causa de todo esto es la IA
  • Estoy escribiendo más software y software más complejo que nunca, pero siento que no estoy creciendo en absoluto como ingeniero
  • Al revisar por qué me sentía "estancado", me di cuenta de que estoy dejando hambriento al Thinker
  • El "vibe coding" claramente satisface al Builder
    • Produce un placer inmediato ver cómo una idea se convierte en realidad en muy poco tiempo
    • En cambio, los momentos en que tengo que pensar por mi cuenta una solución creativa para un problema técnico han disminuido mucho
  • Para las personas con una inclinación puramente Builder, este es el mejor momento posible
  • Pero para mí, claramente falta algo

La trampa del pragmatismo

  • Anticipo la objeción: “si se puede resolver con vibe coding, entonces ese problema nunca fue realmente difícil”
    • Pero ese argumento esquiva el punto central
  • La IA no es especialmente buena para los problemas difíciles, y tampoco da siempre buenas soluciones en los problemas fáciles
    • Si yo reescribiera directamente el mismo módulo por tercera vez, tengo la certeza de que sería mejor que cualquier resultado generado por IA
  • Pero, al mismo tiempo, soy pragmático
  • Si con una fracción mínima del tiempo y del esfuerzo puedo obtener una solución “lo bastante cercana”, sentiría que no elegir la IA es, más bien, lo irracional
    • El verdadero problema es que no puedo desactivar conscientemente ese pragmatismo (no puedo ignorarlo)
  • En esencia soy un Builder, y me gusta el acto mismo de construir. Si puedo construir más rápido, siempre se siente mejor
  • Aunque intentara rechazar la IA y volver a una época en que la necesidad del Thinker se satisfacía de forma natural a través de la programación, al Builder le cuesta tolerar esa ineficiencia
  • La IA casi con certeza no ofrece una solución 100% satisfactoria, pero las soluciones del 70% a las que llega normalmente cumplen con el criterio de ser “lo bastante buenas”

¿Qué hacer de aquí en adelante?

  • Sinceramente, todavía no he encontrado una respuesta, y sigo dándole vueltas
  • No estoy seguro de que estas dos inclinaciones puedan seguir satisfaciéndose al mismo tiempo dentro de un solo ámbito: la programación
  • Existe la opción de proponerse proyectos más difíciles y buscar de forma deliberada problemas en los que la IA fracase por completo
  • A veces me encuentro con ese tipo de problemas, pero siento que los problemas que realmente exigen soluciones profundas y creativas están disminuyendo con rapidez
  • También he intentado recuperar fuera del código la sensación de crecimiento mental
    • Incluso he vuelto a abrir viejos libros de texto para reconectarme con la física
    • Pero eso no se ha traducido en una satisfacción real
    • Cuando tengo la posibilidad de construir algo, me cuesta justificar ante mí mismo dedicar tiempo y energía mental a problemas de física que no son directamente relevantes para el presente ni están al día
  • La inclinación Builder simplemente no permite sentarse a contemplar problemas no resueltos
  • La inclinación Thinker sigue hambrienta mientras el vibe coding continúa
  • No estoy seguro de si volverá a existir un momento en que ambas necesidades puedan satisfacerse al mismo tiempo

“Ahora hemos adquirido el derecho de dar a este ser el nombre familiar con el que siempre se ha señalado aquello a lo que jamás pudieron llegar ni el poder de la imaginación, ni los saltos más audaces de la fantasía, ni la fe más devota, ni el pensamiento abstracto más profundo, ni siquiera una mente arrebatada por el éxtasis. Dios. Pero esta unidad fundamental pertenece al pasado; ya no existe. En el proceso de transformar su propia existencia, se despedazó por completo, de forma total y radical. Dios ha muerto, y su muerte fue precisamente la vida del mundo.”
— Philipp Mainländer

9 comentarios

 
winmain 2026-02-06

Los tipos 1 y 2 ya estaban perdidos desde hace rato,
son programadores sin aptitudes,
y esto solo les provoca sensación de crisis
a personas que apenas se mantienen por mero sentido profesional... En primer lugar, son gente a la que le da flojera
siquiera pensar...

Para los del tipo 3, en cambio, es un regalo bienvenido.
Los del tipo 3 ya lo están aprovechando bien, ¿no?

Cuando sale una herramienta nueva, ¿no se emocionan y la usan bien?

Yo al principio probé con código de win32.
Pero, como era de esperar... estaba al nivel de una Automation Interface
nada más.
Pensé que con una cosa así ya era imposible diseñar software de buena calidad.
Entonces me puse a pensar cómo sacarle el máximo provecho posible.
Pero incluso a este nivel hay mucho para usar.

Esto también, si lo piensas y lo trabajas, es como si te salieran más brazos y piernas... pero yo creo que el problema es que ni siquiera intentan pensar así.

 
savvykang 2026-02-05

De los 5 días laborales, un día trabajo sin usar LLM durante el horario de trabajo, y los domingos directamente no uso LLM; se puede llevar bastante bien.

 
goodnvin 2026-02-06

Solo se están engañando. Si puedes hacer experimentos rápido, te conviene ir probando y acumulando datos; ¿en qué se diferencia eso de decir "ah~ no sé, yo soy de la teoría~"? jajaja
No me parece más que alguien llorando porque al final se demostró que su teoría, que hasta ahora no podía hacerse realidad y por eso no podía probarse, en realidad no servía para nada.
Si de verdad fuera un thinker, en esta situación estaría descubriendo qué problemas resolver a través de la IA y seguiría pensando "todavía" para encontrar una solución mejor.

 
hpark 2026-02-06

No parece ser un comentario con una actitud respetuosa.

 
ahwjdekf 2026-02-05

¿No bastaría con combinar compilación y razonamiento adicionales para mejorar aún más el código generado por la IA?

 
aeolian21 2026-02-05

En sistemas enormes de nivel empresarial, el proceso de elegir el modelo de procesamiento adecuado y definir el enfoque del pipeline sigue siendo un área donde la IA todavía deja que desear en términos de madurez, así que quizá convenga voltear a ver la arquitectura.
Aunque claro, quién sabe cuánto dure eso también...

No queda de otra más que saciar esas ganas resolviendo problemas difíciles de algoritmos y abordar el negocio de forma práctica, supongo.

 
pencil6962 2026-02-05

Me hace pensar que, así como existe el tejido como pasatiempo incluso en una era donde las máquinas hacen la ropa, quizá también pueda existir la programación como hobby.

 
pluto 2026-02-05

Desde un punto de vista muy personal,
creo que quizá se puede hacer cherry-picking de la satisfacción de ser builder y thinker.

Ahora ya es posible crear algo que funcione con un costo totalmente bajo (poco tiempo),
y quedarse con la satisfacción de que los usuarios usen eso, con la satisfacción de haber resuelto un problema de la vida real,

si el tiempo ahorrado se invierte en problemas que requieren pensamiento profundo (de hecho, eso es lo que hago),
creo que eso también tiene su propio significado y su propia satisfacción.

 
GN⁺ 2026-02-05
Opiniones en Hacker News
  • Me impactó el texto de Aral Balkan de marzo de 2025
    Programar es como moldear un bloque de arcilla hasta darle la forma que quieres. En ese proceso aprendes los límites y características del material.
    Antes de construir, es precisamente cuando menos sabes qué quieres construir. Diseñar no es solo resolver problemas, sino descubrir el problema correcto.
    Si te saltas el proceso creativo, pierdes el elemento humano del aprendizaje y el descubrimiento. Una obra que tallaste tú mismo la entiendes a fondo, pero un resultado sacado de una máquina expendedora no es más que una imitación que solo se parece por fuera

    • Cuando programas con herramientas tipo agente, tienes que seguir empujando para que la idea no se degrade hacia una forma promedio
      Cuanto más nueva sea la idea, más intenta la herramienta “normalizarla”, así que hace falta esfuerzo para vencer esa resistencia.
      En ese proceso terminas definiendo con claridad qué es y qué no es tu idea. En cuanto dejas de empujar, el LLM tapa la originalidad del proyecto
    • Yo creo que todo esto es una continuidad de abstracciones. No pasa nada si no construyes tú mismo el OS, el compilador o la librería estándar.
      Mi trabajo es combinar herramientas ya hechas para crear algo nuevo.
      Saltarse parte del proceso creativo no significa que la obra valga menos.
      Por ejemplo, no por usar el motor físico Havok en Zelda, o por estar hecho con Unreal, un juego deja de ser excelente
    • Tras 30 años trabajando en 10 empresas, lo que las empresas esperaban de mí no era “escribir código”, sino generar valor de negocio
      Me siento orgulloso del resultado que construí en las últimas 3 semanas combinando Codex, Claude y sesiones de prueba.
      Antes el objetivo era materializar ideas; ahora el objetivo es satisfacer al cliente y cumplir tiempos y presupuesto
    • También puedes subir un nivel más. En vez de moldear directamente la arcilla, puedes especificar cada pieza y dejar que una máquina la fabrique
      Así puedes construir sistemas complejos formados por miles de piezas.
      Antes ese papel lo cumplía la organización de la empresa: la capa de arriba hacía la especificación y la de abajo fabricaba las piezas
    • Como decía Michelangelo, que “quitó todo lo que no era David”, el trabajo está influido por el medio
      Antes podías reconocer enseguida un sitio hecho con Ruby on Rails.
      Si encargas trabajo a una persona o a un agente sin entender las características del medio, aparece la diferencia entre código limpio y código imposible de mantener
      Al final la responsabilidad es de quien da las instrucciones. Sin experiencia en el medio, no estás preparado para evaluar el resultado
  • Yo simplemente tecleo menos, pero sigo pensando igual
    Las herramientas mejoraron, pero programar sigue siendo programar.
    Da igual si cruzas el desierto en camello o en helicóptero: al final el viaje sigue siendo un viaje.
    Que las herramientas hayan avanzado no significa que la esencia haya cambiado

    • Al ver los comentarios de este post, sorprende la falta total de intento por entender la experiencia ajena
      Parece que olvidaron que pueden coexistir experiencias distintas.
      Me llamó especialmente la atención el comentario de “no quiero pensar”
    • No tiene nada de malo volar sobre el desierto en helicóptero, pero no es la misma experiencia que recorrerlo a pie
      Está bien subir al siguiente nivel de abstracción, pero también hay que reconocer el valor que se pierde en el proceso
    • Entiendo lo que dice el autor. Extrañamos la época en la que pensábamos en los detalles finos
      Los LLM son solo una evolución de las herramientas, pero da pena que desaparezca ese proceso de pensamiento minucioso
    • Pero programar con LLM no es una simple abstracción.
      Más bien se parece a poner a otra persona a trabajar y luego revisar lo que hizo.
      A quienes no les gustaba programar les encantará, pero a esto no se le puede llamar “programar”
    • Después de programar con agentes, siento que mi modelo mental se debilita
      Cuando escribo el código yo mismo, puedo visualizar la estructura de datos en mi cabeza, pero cuando el agente lo hace por mí, esa sensación desaparece.
      Hacer commit de código sin entenderlo no tiene valor para mí
  • Equiparar la programación con LLM a las abstracciones tradicionales es una analogía equivocada
    Los compiladores o frameworks apuntan a ser abstracciones sin fugas, pero los LLM tienen fugas por naturaleza
    Al final, encontrar y corregir bugs sigue siendo tarea humana.
    En cierto sentido, los LLM volvieron a introducir la incertidumbre y el riesgo que intentábamos evitar

    • Programar con LLM es, al final, descomprimir un prompt en código
      Si no explicitas todas las variables en el prompt, sale un resultado promedio.
      Queda la duda de si el lenguaje natural realmente sirve para contener ese tipo de información
    • Los LLM actuales se parecen a un practicante torpe. Pero si un experto humano puede producir código sin fugas, quizá algún día un LLM también pueda hacerlo
    • Como los LLM son no deterministas, no hay que versionar la entrada sino el resultado de salida
      Eso no es abstracción, sino generación de código no determinista
    • Si un compilador de C a veces no funcionara, probablemente solo seguiríamos apretando el botón de build hasta que saliera
      En ese sentido, los LLM también influyen de otra manera en la forma de pensar humana
    • Parece que muchos desarrolladores no entienden bien qué significa realmente “abstracción”
  • Yo soy más bien un thinker, así que la programación con AI no me interesa mucho
    Disfruto crear yo mismo cosas como un kernel de OS o un motor gráfico.
    Más que el resultado, lo que me gusta y me da satisfacción es el proceso de resolver el problema
    En cambio, los builders se entusiasman porque con AI pueden construir más rápido

    • Pero esa división de “builder = alguien que no piensa” es falsa
      Todo ingeniero piensa. Lo que cambia es el propósito de la herramienta
  • Después de décadas programando, las herramientas de AI me dan libertad
    Puedo experimentar rápido con ideas que antes ni siquiera habría intentado.
    Gracias a eso, puedo avanzar proyectos personales aprovechando pequeños fragmentos de tiempo

    • Me parece interesante eso de llevar un proyecto desde el teléfono. Me da curiosidad cómo lo haces
    • En una vida con familia, la capacidad de convertir momentos cortos en progreso real es enorme
    • También estoy de acuerdo con esto. Gran parte de la programación era desperdicio de boilerplate
      Gracias a la AI ahora puedo concentrarme en el pensamiento de verdad.
      Ya siento que la singularidad se está acercando
    • En una tarde puedes probar varios enfoques.
      Si fallan, igual aprendes; si funcionan, puedes concentrarte en validar la calidad
  • Pensar” también tiene varias formas
    Está el pensamiento intenso y concentrado, y está el pensamiento que madura lentamente en segundo plano.
    Ambos son formas de inmersión profunda, y son cosas que en la era de la AI se pueden perder con facilidad

    • Yo también tengo varios tipos de ‘hard thinking’
      Resolver problemas matemáticos, pensar filosóficamente o lidiar con restricciones complejas del trabajo me da diferentes formas de tensión intelectual
      Al final, lo importante es la experiencia de sumergirse a fondo en cualquiera de esas formas
  • Entre los ingenieros senior que conozco veo dos grupos
    Algunos consiguieron una ligera mejora de productividad, pero también hay quienes perdieron profundidad de pensamiento
    Muchas veces solo copian y pegan la respuesta que les dio el LLM.
    El problema real es la falta de capacidad para hacer bien las preguntas

    • Más que la implementación, el problema grande es el overhead de comunicación.
      En sistemas maduros, esa proporción supera el 90%
  • Me decepciona ver a colegas ingenieros entusiasmarse con la AI y entregar la esencia misma de su profesión
    Teníamos los medios de producción y aun así los cedimos por voluntad propia

    • A corto plazo puede haber desempleo, pero la demanda de software es infinita
      Si gracias a la AI desarrollar se vuelve más barato y más rápido, el mercado incluso podría crecer
    • Confiar en la AI y oponerse a ella al mismo tiempo es contradictorio.
      El avance tecnológico siempre perjudica a ciertos oficios, pero trae progreso para la sociedad en su conjunto
      Así como antes nosotros redujimos empleos en otras industrias mediante la automatización, ahora simplemente nos tocó el turno
    • El problema son los pragmatistas que solo buscan eficiencia sin valor
      El resultado no puede ser más que vacío. Aunque quizá, para ellos, incluso eso era el objetivo
    • Esta capa se parece al proceso en que la pequeña burguesía es absorbida por una burguesía mayor
    • Es el resultado del tecnicismo sin ética ni filosofía
      La lógica de “se puede hacer, así que se hace” termina despojándonos de humanidad
  • La AI no elimina el pensamiento. El problema son las empresas mediocres y las formas mediocres de pensar
    Hay que ir a empresas donde de verdad se valore pensar

  • Yo también programo con LLM, pero igual pienso a fondo
    Pienso en diseño, riesgos, restricciones, deuda técnica, alternativas, etc.

    • Pero pensar junto con un LLM es otro tipo de pensamiento
      Se parece más a una “gestión de contexto”, moviéndote entre varios contextos a la vez,
      y no al pensamiento de tipo científico que se sumerge durante días en un solo problema
    • Mi experiencia es parecida. Gracias al LLM, programar se volvió más fácil, pero validar y revisar se volvió mucho más difícil
      En especial, los PR de juniors que usan AI se hicieron más largos y complejos,
      y ahora la mayor parte de mi trabajo se volvió centrada en la revisión
    • Los LLM son más eficientes cuando se usan para tareas repetitivas y pequeñas
      Son útiles para prototipos rápidos, funciones helper, autocompletado de código, exploración de librerías, etc.
    • Incluso si Claude Code genera el 100% del código, la proporción de pensamiento profundo sigue siendo alta
      De hecho, como disminuyen las tareas simples, termino pensando más
    • Pero después de los LLM desaparece el bucle de retroalimentación sobre el código mismo
      Antes, escribir código te hacía volver a examinar el pensamiento de diseño de nivel superior,
      pero ahora ese proceso se reduce y uno termina pensando “menos profundamente”