On April 20th, the #1 post on Hacker News wasn’t about a new model, a faster agent, or a framework that writes code for you. It was a short blog post by Ashley Rolfmore titled “Stop trying to engineer your way out of listening to people.”
146 points. 51 comments. On a Sunday.
Timing matters. We’re in April 2026. Every week brings a new AI coding tool, a new agent architecture, a new plugin that promises to close the gap between what you want and what actually gets built. And what resonated most with the HN community that day was someone saying: the gap isn’t technical. It’s human.
I’ve spent twenty years in tech leadership. I can tell you with certainty: the projects that failed hardest weren’t the ones with bad tools. They were the ones nobody listened to.
What Rolfmore Actually Said
The post is short — a 3-minute read that lists nine traps that prevent people from actually listening. It’s not specifically about AI. It’s about product teams, designers and developers who substitute frameworks and systems for the hard work of understanding what people actually need.
Some of his points hit especially hard in 2026:
“You assume ‘technical’ is one thing.” Developers treat “technical” as a binary — either you are or you aren’t. But technical knowledge is a spectrum of deeply different domains. A backend engineer, a data scientist, and a DevOps specialist live in completely different worlds. When you flatten all that into “technical people,” you stop listening to what each one actually knows.
“You underestimate how much your specialization shapes your worldview.” You spend years learning a domain and develop a set of assumptions about what’s obvious. It isn’t. The person across the table knows different things, not fewer things.
“You assume what they say is the same as what they think.” Some people say what they mean. Many don’t. And most believe they’re saying what they mean but actually aren’t.
These aren’t new ideas. But the fact that they hit #1 on Hacker News in 2026 — the year of autonomous coding agents — tells you something.
The Paradox of AI Tools
This is what I think is really happening. The explosion of AI tools over the last two years has given developers more power than ever to build things fast. Claude Code can implement a feature in minutes. Cursor can scaffold an entire module. Windsurf can run agents in parallel across the same repo. The speed is real.
But speed without direction is just movement. And direction comes from understanding — from listening to the person who’s going to use what you’re building, and really grasping what they need versus what they’re asking for.
The irony is that AI tools can amplify listening failures at unprecedented speed. Before, if you misunderstood a requirement, you’d spend a week building the wrong thing. Now you can build the wrong thing in twenty minutes. The feedback loop is faster, but only if you’re paying attention. If you’re not listening, you’re just producing wrong answers faster.
A HN commenter put it well: product managers jump to solutions — a new feature, a ticket — when they should be absorbing the use case and identifying the real pain point. That pattern gets worse, not better, when you have an AI agent that can execute against a bad spec instantly.
The Counterargument Worth Taking Seriously
The most thoughtful pushback in the HN thread came from a commenter who argued that relying on systems and frameworks isn’t evasion — it’s a practical response to the fact that individual behavior doesn’t scale. You can’t challenge every human in an organization to listen better. Systems can build mechanisms for detecting gaps and translation that help teams communicate even when individuals aren’t perfect communicators.
It’s a valid point. And it’s one I’ve seen in practice. The best engineering organizations I’ve worked with don’t depend on individual brilliance in communication. They build processes that surface misunderstandings early — structured kickoffs, written specs reviewed before code starts, regular check-ins where the question isn’t “what did you build” but “does this match what you expected.”
But here’s the thing: those processes only work if someone designed them with listening in mind. A standup nobody pays attention to is just a meeting. A requirements document nobody reads is just a file. The system doesn’t replace the skill — it creates the space where the skill can operate.
What This Means for Development Teams in Latin America
I want to connect this to something specific to our context. Development teams in Latin America frequently work with distributed stakeholders — product managers in the United States, European clients, remote-first organizations where async communication is the default. The listening problem is harder when you’re working across time zones, languages, and cultural norms about how direct you should be.
AI tools don’t solve this. In fact, they can make it worse. When a team in Buenos Aires receives a vague spec from a product manager in San Francisco and throws it at an AI agent, the agent will produce something. It will produce it fast. And it could be completely wrong, because the actual requirement was never articulated — it was implicit in a context that didn’t survive the async handoff.
The teams that are going to win in this environment aren’t the ones with the best AI tools. They’re the ones who combine the speed of AI with the discipline to pause, ask questions, and verify that what they’re building is what’s actually needed.
The Uncomfortable Truth
We love tools because tools are controllable. You configure them, you run them, you evaluate their output. People are messy. They contradict themselves. They don’t know what they want until they see what they don’t want. Listening to people is fundamentally uncomfortable because it forces you to sit with ambiguity.
But every misunderstanding that makes it into code becomes technical debt. Rolfmore says it straight: every communication failure adds something to the codebase you’re going to have to deal with later. In 2026, when AI agents can generate code at scale, the cost of a misunderstanding isn’t one bad feature — it’s dozens of generated files built on a wrong assumption.
The post hit #1 on Hacker News because developers know this. They feel it every day. And all the AI tools in the world aren’t going to engineer a way out of it.
The work is listening. It always was.
Original post: Stop trying to engineer your way out of listening to people by Ashley Rolfmore.
The discussion on HN: thread on Hacker News — worth reading the comments, where the community debates whether systems can substitute for individual listening skills.
What’s your experience? Do your AI tools help you understand requirements better, or do they just let you build the wrong thing faster? Let us know in the comments. 