El 20 de abril, el post #1 de Hacker News no era sobre un modelo nuevo, un agente más rápido, ni un framework que escribe código por vos. Era un blog post corto de Ashley Rolfmore titulado “Stop trying to engineer your way out of listening to people.”
146 puntos. 51 comentarios. Un domingo.
El timing importa. Estamos en abril de 2026. Cada semana trae una nueva herramienta de coding con IA, una nueva arquitectura de agentes, un nuevo plugin que promete cerrar la brecha entre lo que querés y lo que se termina construyendo. Y lo que más resonó con la comunidad de HN ese día fue alguien diciendo: la brecha no es técnica. Es humana.
Llevo veinte años en liderazgo tecnológico. Puedo decirte con certeza: los proyectos que más fuerte fracasaron no fueron los que tenían malas herramientas. Fueron los que nadie escuchó.
Lo Que Rolfmore Realmente Dijo
El post es corto — una lectura de 3 minutos que lista nueve trampas que impiden que la gente realmente escuche. No es específicamente sobre IA. Es sobre equipos de producto, diseñadores y desarrolladores que sustituyen frameworks y sistemas por el trabajo difícil de entender lo que la gente realmente necesita.
Algunos de sus puntos pegan especialmente fuerte en 2026:
“Asumís que ‘técnico’ es una sola cosa.” Los desarrolladores tratan “técnico” como un binario — o lo sos o no lo sos. Pero el conocimiento técnico es un espectro de dominios profundamente diferentes. Un backend engineer, un data scientist y un especialista en DevOps viven en mundos completamente distintos. Cuando aplanás todo eso en “gente técnica,” dejás de escuchar lo que cada uno realmente sabe.
“Subestimás el efecto de la especialización en tu propia visión del mundo.” Pasás años aprendiendo un dominio y desarrollás un set de supuestos sobre lo que es obvio. No lo es. La persona del otro lado de la mesa sabe cosas diferentes, no menos cosas.
“Asumís que lo que dicen es lo mismo que lo que piensan.” Algunas personas dicen lo que quieren decir. Muchas no. Y la mayoría cree que dice lo que quiere decir pero en realidad no lo está haciendo.
No son ideas nuevas. Pero el hecho de que llegaran al #1 de Hacker News en 2026 — el año de los agentes de coding autónomos — te dice algo.
La Paradoja de las Herramientas de IA
Esto es lo que creo que realmente está pasando. La explosión de herramientas de IA de los últimos dos años les dio a los desarrolladores más poder que nunca para construir cosas rápido. Claude Code puede implementar un feature en minutos. Cursor puede scaffoldear un módulo entero. Windsurf puede correr agentes en paralelo sobre el mismo repo. La velocidad es real.
Pero velocidad sin dirección es solo movimiento. Y la dirección viene de entender — de escuchar a la persona que va a usar lo que estás construyendo, y realmente captar lo que necesita versus lo que está pidiendo.
La ironía es que las herramientas de IA pueden amplificar fallas de escucha a una velocidad sin precedentes. Antes, si malinterpretabas un requerimiento, pasabas una semana construyendo lo incorrecto. Ahora podés construir lo incorrecto en veinte minutos. El feedback loop es más rápido, pero solo si estás prestando atención. Si no estás escuchando, simplemente estás produciendo respuestas equivocadas más rápido.
Un comentarista de HN lo puso bien: los product managers saltan a soluciones — un feature nuevo, un ticket — cuando deberían estar absorbiendo el caso de uso e identificando el pain point real. Ese patrón empeora, no mejora, cuando tenés un agente de IA que puede ejecutar sobre un spec malo al instante.
El Contraargumento Que Vale la Pena Tomar en Serio
El pushback más reflexivo en el thread de HN vino de un comentarista que argumentó que recurrir a sistemas y frameworks no es evasión — es una respuesta práctica al hecho de que el comportamiento individual no escala. No podés retar a cada humano de una organización para que escuche mejor. Los sistemas pueden construir mecanismos de detección de gaps y traducción que ayudan a los equipos a comunicarse incluso cuando los individuos no son comunicadores perfectos.
Es un punto válido. Y es uno que vi en la práctica. Las mejores organizaciones de ingeniería con las que trabajé no dependen de brillantez individual en comunicación. Construyen procesos que hacen emerger malentendidos temprano — kickoffs estructurados, specs escritos que se revisan antes de que arranque el código, check-ins regulares donde la pregunta no es “qué construiste” sino “esto coincide con lo que esperabas.”
Pero acá está la cuestión: esos procesos solo funcionan si alguien los diseñó con la escucha en mente. Un standup al que nadie le presta atención es solo una reunión. Un documento de requerimientos que nadie lee es solo un archivo. El sistema no reemplaza la habilidad — crea el espacio donde la habilidad puede operar.
Qué Significa Esto para Equipos de Desarrollo en Latinoamérica
Quiero conectar esto con algo específico de nuestro contexto. Los equipos de desarrollo en Latinoamérica frecuentemente trabajan con stakeholders distribuidos — product managers en Estados Unidos, clientes europeos, organizaciones remote-first donde la comunicación async es el default. El problema de escuchar es más difícil cuando trabajás cruzando zonas horarias, idiomas y normas culturales sobre qué tan directo deberías ser.
Las herramientas de IA no resuelven esto. De hecho, pueden empeorarlo. Cuando un equipo en Buenos Aires recibe un spec vago de un product manager en San Francisco y se lo tira a un agente de IA, el agente va a producir algo. Lo va a producir rápido. Y puede estar completamente equivocado, porque el requerimiento real nunca se articuló — estaba implícito en un contexto que no sobrevivió el handoff async.
Los equipos que van a ganar en este entorno no son los que tienen las mejores herramientas de IA. Son los que combinan la velocidad de la IA con la disciplina de pausar, hacer preguntas y verificar que lo que están construyendo es lo que realmente se necesita.
La Verdad Incómoda
Nos encantan las herramientas porque las herramientas son controlables. Las configurás, las corrés, evaluás su output. Las personas son desordenadas. Se contradicen. No saben lo que quieren hasta que ven lo que no quieren. Escuchar a la gente es fundamentalmente incómodo porque te obliga a convivir con la ambigüedad.
Pero cada malentendido que llega al código se convierte en deuda técnica. Rolfmore lo dice directo: cada falla de comunicación agrega algo al codebase con lo que vas a tener que lidiar después. En 2026, cuando los agentes de IA pueden generar código a escala, el costo de un malentendido no es un feature malo — son docenas de archivos generados construidos sobre un supuesto incorrecto.
El post llegó al #1 de Hacker News porque los desarrolladores saben esto. Lo sienten todos los días. Y todas las herramientas de IA del mundo no van a engineerear una salida de eso.
El trabajo es escuchar. Siempre lo fue.
El post original: Stop trying to engineer your way out of listening to people de Ashley Rolfmore.
La discusión en HN: thread en Hacker News — vale la pena leer los comentarios, donde la comunidad debate si los sistemas pueden sustituir las habilidades individuales de escucha.
¿Cuál es tu experiencia? ¿Tus herramientas de IA te ayudan a entender mejor los requerimientos, o simplemente te dejan construir lo incorrecto más rápido? Contanos en los comentarios. 