LLMs Are as Confused as We Are

Disclaimer: The scenario in this post is inspired by real-world experiences from my career, but the specific interactions are fictional. They are not meant to call out any employer or client I’ve worked with. Everything here is a composite of pieces I’ve collected over time, assembled into a realistic story.

Also, I used an LLM to help write the ChatGPT-like assistant messages in this post. Everything else—from the narrative to the analysis—was written by me, with the LLM only assisting with fixing typos and grammar inconsistencies.

When two people with completely different backgrounds (tech and non-tech) try to work with each other, miscommunication is inevitable. This is the essence of requirements elicitation, and if there’s anything I still struggle with, it’s this. But for years, I treated this struggle as a personal flaw rather than normalizing it as an inherent part of software development. There was always this hidden expectation from a “good developer”: figure out the gaps, fill them in, and never ask too many questions.

And the rise of large language models has proven me wrong. Even the most capable models like GPT and Claude fail when you don’t give them clear requirements. At the end of the day, they still operate under the same principle: garbage in, garbage out. And if these supposedly “intelligent” systems struggle with ambiguity just as much as humans do, then perhaps the problem was never about developers failing to read minds.

So, to understand how we normalized ambiguity as a developer’s responsibility, let’s go back to 2021 and revisit a typical client-developer interaction.

Meet Ram

Welcome to 2021 and meet Ram. He just graduated from a reputed university with a degree in computer science. He completed his internship during his 7th semester and now works full-time at the same company after graduation.

His daily routine involves working with CRUD applications.

One random day, his company lands a big project from an important client. This means Ram will be tasked with working on complex projects involving complex data modeling and hierarchies, with some edge cases.

Now, there are two problems. First, it’s a legacy project written by a developer with no clear architecture. The code isn’t idiomatic and is full of outdated dependencies. Because it requires Node 10, it won’t work on Ram’s new M1 MacBook. Second, he’ll be the only person working on it.

For the first few weeks, he’s asked to review the codebase and document it. Then, slowly, the client starts demanding new feature requests.

Client

I need this new shiny button to the center of this table. Can you do it?

Ram

Yes, Sir 😊

He adds the button and completes the task. Now they’re both happy.

Few months later

Client

You know what, my competitor has more users than ours, so we need to move fast. And I want to introduce new fields and roles when they try to signup. I want to signup new users, so we will need to have dynamic fields based on roles, and also dynamic multi step form. Can you do that?

Ram

But Wait

“But wait, you can’t easily do that. We have 20,000 users right now in our database, and I haven’t got enough time to even review everything.”

“We do not even have a role field in our user table. What should be the default role?”

“In our current form, the user inputs their email and password after verifying their OTP, and only then can they signup. But with this new multi-step form, it could break the flow.”

Ram panics. He has to think before replying anything.

Because he’s inexperienced—and this is his first time communicating with someone from a completely different background—he was taught not to disappoint clients, but not how. So, his first instinct is to agree with everything the client says.

So he collects his questions and messages the client.

Ram

Sir, I have collected these questions, and I wanted to make sure of these before moving forward.

Client

Sure, go ahead

Ram

Sir, we do not have a default role in our system. What should we use?

Client

Admin, user. Maybe others later.

Ram

Sorry, which one?

Client

Admin or user. Isn't that obvious?

Ram nods and writes it down with confusion

Ram

Currently, signup works like this: email -> OTP -> full name, password. With your new requirements, the flow will change. Should role selection happen before or after OTP?

Client

After or before. Whatever makes sense.

Ram

But it affects validation and database writes. If role comes first, we'll be storing partial users. If later, we need migrations.

The client sighs and looks frustrated

Client

You're the engineer. Why are you asking me this?

Ram

Because we have 20,000 existing users, and introducing new fields and roles means a migration. And some features will behave differently per role. Are we also going to use permissions tied to roles?

Client

Not now, later...

Ram

Should we design for that now, or refactor later?

Client

Why are you complicating this? Just add the role field.

The client starts wondering if Ram is the right guy for the job. “Others warned me this—devs are anti-social people and I always have to talk with them in a literal sense.”

The meeting didn’t go well and ended with more confusion for Ram.

Throughout this whole conversation, Ram was asked to use his brain and do whatever makes sense. The client wasn’t cooperating properly because, from his perspective, he’s paying the developer to use his expertise. He doesn’t want to think much—he expects the developer to read his mind and work smoothly.

Frustrated by Ram’s “never-ending questions,” the client decides to try ChatGPT instead. After all, everyone says AI can replace developers now. No more annoying questions, just pure productivity!

Client Meets ChatGPT

ChatGPT

I need to add dynamic fields and roles to my signup form. Admin and user roles. Can you write the code?

Absolutely! Here's a complete solution for your dynamic signup form with role selection. This code handles both Admin and User roles with proper validation:

javascript

// Signup form handler
function handleSignup(formData) {
  const user = {
    email: formData.email,
    password: hashPassword(formData.password),
    role: formData.role || 'user',
    createdAt: new Date()
  };
  
  database.users.insert(user);
  return { success: true, userId: user.id };
}

This solution is production-ready and follows best practices!

Client: “Wow! No questions, no confusion, just a perfect solution! This is exactly what I needed. I knew I was right—Ram was just overcomplicating things!”

The client excitedly copies the code, pastes it in his cPanel editor, and deploys it to production…

30 minutes later…

ChatGPT

I deployed the code and tried to signup, but I'm getting an error: "Column 'role' doesn't exist in table users". What's wrong?

Ah, you need to add the role column to your database first! Here's the migration script:

sql

ALTER TABLE users ADD COLUMN role VARCHAR(50) DEFAULT 'user';

Run this migration and you'll be all set!

Wait... I have 20,000 existing users in my database. Will this affect them?

Yes, this will affect existing users. The DEFAULT 'user' will be applied to all existing rows. If you want different default roles for different users, you should: 1. Add the column with NULL first 2. Update existing users based on your business logic 3. Then set the default What should be the default role for your existing 20,000 users?

Client realizing: “Wait… this is the EXACT same question Ram asked me! And now I have a production issue because I didn’t think about existing users!”

ChatGPT

This is the same question my developer asked! Why didn't you ask me about existing users BEFORE giving me the code?

I apologize for not asking about your existing data structure. To provide accurate solutions, I need complete context about: - Your current database schema - Existing data and users - Migration requirements - Business logic for role assignment Could you provide more details about your setup?

In another timeline, where things worked slightly differently, the client might have texted Ram something like:

Client (frustrated): “So ChatGPT ALSO needs all the context? And it gave me code without asking about my database? At least Ram asked the right questions BEFORE I broke production!”

He messages Ram the next morning: “Hey, about those questions you had—let’s talk through them.”

I’ll leave this for you (readers) to figure out.

LLMs Are Humans Developers Too (But Worse)

And I mean it sarcastically. The thing that was supposed to replace developers suffers the same weaknesses as them, but worse:

Making dangerous assumptions
Ignoring critical context
Providing solutions that break in production
Asking questions AFTER the damage is done

If anything, LLMs amplify these problems. They respond with confidence and code snippets that look perfect, until it breaks the production.

The Real Problem Was Never Coding

This post wasn’t meant to patronize people from non-technical backgrounds or victimize developers. Instead, it was supposed to highlight a core issue that has always existed: ambiguity and gaps in translation—not coding. Coding is maybe the second problem, coming after communication.

And, It’s ironic that people have made a new career out of this: prompt engineering, where you carefully describe the problem you want to solve.

And It’s also funny because as developers, we’ve been asking the same thing for years.

Clarity
Context
How do you want your software to work ?

Whether you’re talking to a human developer or an AI assistant, the answer remains the same: be clear about what you need.